Wondering: why capabilities system is broken?

Wondering: why capabilities system is broken?

[Michael Tokarev]

Hopefully not a flamewar question...

Currently, capabilities of a process are reset during exec()
system call.  At least effective+permitted set.

1) In case new uid != 0, all the caps are cleared, so it is not
possible to execute a program as non-root but still give it some
capabilities (like, say, CAP_NET_BIND_SERVICE).

2) In case new uid == 0, effective and permitted sets are restored
to all-ones.

This is regardless of other settings, like prctl(KEEPCAPS), or
the current set of capabilities.

I partly understand why 2) is done - in case of setuid binary being
executed, all the capabilities are set for it.  But this breaks
executing non-setuid binaries too -- for example, it'd be very nice
to be able to chroot to some directory, and remove CAP_SYS_CHROOT
(and other evil caps like CAP_SYS_MODULE, CAP_SETPCAP) -- this way,
with minimal efforts, chroot will work almost (yes, I understand
it's not entirely the same) the same as BSD jail(2) concept.

So the question is: why capability sets are being reinitialized during
exec()?  At least in 2.4 era, they weren't...  and stuff like
execcap, sucaps etc was working.  Now they aren't anymore.

Thanks.

/mjt

Re: Wondering: why capabilities system is broken?

[Serge E. Hallyn]

Quoting Michael Tokarev (mjt@tls.msk.ru):
> Hopefully not a flamewar question...

nothing wrong with asking for clarification.  Though you should have
copied linux-security-module@vger.kernel.org.

> Currently, capabilities of a process are reset during exec()
> system call.  At least effective+permitted set.
> 
> 1) In case new uid != 0, all the caps are cleared, so it is not
> possible to execute a program as non-root but still give it some
> capabilities (like, say, CAP_NET_BIND_SERVICE).

With the introduction of file capabilities in -mm, you can assign
CAP_NET_BIND_SERVICE to a program not owned by root such that all users
can run the program with that capabilities.

Even in mainline, you can make the program setuid 0 and code it such
that it immediately specify keepcaps, change to nonroot, and drop all
caps but CAP_NET_BIND_SERVICE.

> 2) In case new uid == 0, effective and permitted sets are restored
> to all-ones.
> 
> This is regardless of other settings, like prctl(KEEPCAPS), or
> the current set of capabilities.

Look at the prctl(2) manpage - it is about keeping capabilities across
setuid, not across exec.

> I partly understand why 2) is done - in case of setuid binary being
> executed, all the capabilities are set for it.  But this breaks
> executing non-setuid binaries too -- for example, it'd be very nice
> to be able to chroot to some directory, and remove CAP_SYS_CHROOT
> (and other evil caps like CAP_SYS_MODULE, CAP_SETPCAP) -- this way,
> with minimal efforts, chroot will work almost (yes, I understand
> it's not entirely the same) the same as BSD jail(2) concept.

Are you aware of the namespace/containers work going on right now to get
full virtual server support into mainline?  See
http://lists.linux-foundation.org/pipermail/containers/
for the archives of the main relevant mailing list.

> So the question is: why capability sets are being reinitialized during
> exec()?  At least in 2.4 era, they weren't...  and stuff like
> execcap, sucaps etc was working.  Now they aren't anymore.

Please see the file capabilities support in -mm and let us know whether
that does (not) meet your needs.

thanks,
-serge