Re: posix capabilities inheritance

[Andy Lutomirski <luto@stanford.edu>]

Thanks to everyone for making me realize just how complex / screwed up all of 
this is.  I think it's fair to say that something should be fixed/changed, but I 
don't think that a quick patch is a good idea -- currently capabilities are so 
limited that there is little userspace use, and the use that exists is pretty 
much limited to Ernie's example.  Witness the fact that my patch, as well as 
others, appear to break _nothing_.  That means that we have the opportunity (2.7 
timeframe here) to overhaul the system _once_.


At the risk of premature discussion, here are some thoughts:


1. pI is currently almost useless.  If a process really wants a capability to be 
dropped after exec, it can drop it itself.  So redefine pI to mean "these are 
the only capabilities that this process or its children may _ever_ hold."

2. fE is useless.  It doesn't seem to have much of a point, and it just adds 
complexity.  (e.g. look at Windows privileges.  they start unenabled, and 
programs have to jump through hoops to use them.  I see no security benefit.) 
So remove fE entirely.

3. The current use of the capability bits is not as fine-grained as it could be, 
and lacks the ability to restrict normal users.  Redefine it as:
  Capability range             Function
  ----------------             -----------------
  <0                           On by default
  0-31                         Legacy bounds (see below)
  >=32                         Off by default

All of the current capabilities retain their current values.  New capabilities 
above 32 can have a "legacy bound" associated with them, like this:

_u32 legacy_bounds[] = {...};

bool capable(int cap)
{
	if(x<32) return (cap in effective set);
	else return ( (legacy_bounds[cap] & (bits 0-31 of effective set))
	 && (cap in effective set) );
}

This ensures that existing programs that think they have dropped capabilities 
(using the old numbering) really have dropped those capabilities.  New programs 
can do whatever they want, using the new numbering.  Some random thoughts of 
what the "new" capabilities might look like (where CAP_USER_ means <0 and 
CAP_ADM_ means >=32):

Completely new things:
CAP_USER_FSUID /* permission checks can use fsuid */
CAP_USER_FSGID /* permission checks can use fsgid */
CAP_USER_FSWRITE /* can write files */
Saner version of existing features (CAP_SYS_ADMIN, anyone?)
CAP_ADM_MOUNT_BLOCK /* can mount block devices */
CAP_ADM_MOUNT_NONE /* can mount things that are not block devices */

This could be very nice for administrators.  Maybe a large block of capability 
space could be reserved for userspace use.  (Make capabilities 64 bits?  Fun!) 
Albert -- this fixes one of your complaints.


Capability evolution might look like this:
pI' = pI & fI
pP' = ((fP & X) | pP) & pI'
pE' = pP' & (pE|fP) & (only caps <0 if uid==0 and setuid nonroot)

By the way, even if people are scared of programs mishandling fP!=0, this still 
seems very useful just to adjust "per-user" rights.

If there's enough interest, I might try to implement this in the next few weeks 
and get it ready for 2.7.  There's the risk that if any new scheme goes into a 
mainline development kernel, then people will start using it, and it will be 
impossible to change it, which is why I'm floating this around now.  I don't see 
any reason to keep the current system, and, given that there is no de-facto *nix 
capability standard, Linux might as well have the best capability system out there.

Any thoughts/suggestions/flames?

Andy