lkml.org 
[lkml]   [2003]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: posix capabilities inheritance
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:1.228 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site