<p dir="ltr"><br>
On Jul 20, 2015 4:20 AM, "Florian Weimer" <<a href="mailto:fweimer@redhat.com">fweimer@redhat.com</a>> wrote:<br>
><br>
> On 07/18/2015 03:53 PM, Andrew Lutomirski wrote:<br>
><br>
> > Nothing. Inheritable capabilities are nearly useless.<br>
><br>
> Wow.<br>
><br>
> The program that sparked this thread is a Go program. So basically, we<br>
> have these options if we do not want to run with full capabilities:<br>
><br>
> (a) Run with UID=0 with restricted capabilities, like many systemd<br>
> services already do. Do not use fscaps (which are not needed because of<br>
> the UID=0 special case). This is rather pointless because UID=0 does<br>
> not need capabilities to compromise the system.<br>
><br>
> (b) Make a copy of the file, put it in a directory which only the<br>
> service user can read (or ship it with 750 permissions and the service<br>
> group controlling it), and set fscaps. The downside is the large binary<br>
> size (it has to be a copy, a link won't work). And the service user<br>
> could still run the service with command line options that allow<br>
> privilege escalation.<br>
></p>
<p dir="ltr">If you set inheritable fscaps but not permitted, this should be reasonably safe.</p>
<p dir="ltr">Alas, you will have to remove fscaps entirely to be compatible with ambient caps.</p>
<p dir="ltr">--Andy<br></p>
<p dir="ltr">--Andy</p>