<p dir="ltr"><br>
On Jul 21, 2015 4:18 AM, &quot;Florian Weimer&quot; &lt;<a href="mailto:fweimer@redhat.com">fweimer@redhat.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On 07/20/2015 07:30 PM, Andrew Lutomirski wrote:<br>
&gt;<br>
&gt; &gt;&gt; (b) Make a copy of the file, put it in a directory which only the<br>
&gt; &gt;&gt; service user can read (or ship it with 750 permissions and the service<br>
&gt; &gt;&gt; group controlling it), and set fscaps.  The downside is the large binary<br>
&gt; &gt;&gt; size (it has to be a copy, a link won&#39;t work).  And the service user<br>
&gt; &gt;&gt; could still run the service with command line options that allow<br>
&gt; &gt;&gt; privilege escalation.<br>
&gt; &gt;&gt;<br>
&gt; &gt;<br>
&gt; &gt; If you set inheritable fscaps but not permitted, this should be reasonably<br>
&gt; &gt; safe.<br>
&gt;<br>
&gt; Empirically, this causes the capability to end up in the P set, not the<br>
&gt; E set, which means that the application still needs to be capability to<br>
&gt; enable it.  So it really doesn&#39;t help that much in the Go case, sadly.<br>
&gt; Although it is fairly close.</p>
<p dir="ltr">Try 2: set the capability in the inheritable set and set the effective bit.  (The effective fscap is a single bit, not a mask.  You still program it with &quot;=ei&quot; because the syntax is wrong.)</p>
<p dir="ltr">--Andy</p>
<p dir="ltr">&gt;<br>
&gt; --<br>
&gt; Florian Weimer / Red Hat Product Security<br>
&gt; --<br>
&gt; devel mailing list<br>
&gt; <a href="mailto:devel@lists.fedoraproject.org">devel@lists.fedoraproject.org</a><br>
&gt; <a href="https://admin.fedoraproject.org/mailman/listinfo/devel">https://admin.fedoraproject.org/mailman/listinfo/devel</a><br>
&gt; Fedora Code of Conduct: <a href="http://fedoraproject.org/code-of-conduct">http://fedoraproject.org/code-of-conduct</a></p>