Messages in this thread | | | Date | Fri, 14 May 2004 14:11:45 -0700 | From | Chris Wright <> | Subject | Re: [PATCH] capabilites, take 2 |
| |
* Albert Cahalan (albert@users.sourceforge.net) wrote: > On Fri, 2004-05-14 at 14:06, Stephen Smalley wrote: > > You missed the point. Capability scheme maps far too > > many operations to a single capability; CAP_SYS_ADMIN > > in Linux is a good example. > > What I said: lovely, but not exactly groundbreaking. > > Suppose we break up CAP_SYS_ADMIN into 41 other bits. > There you go. It's silly to argue that a system with > more bits is some kind of major advance over one with > just a few bits. There is a quality-of-implementation > issue here, not some fundamental difference.
Needing more bits isn't the only problem.
> > TE model > > defers organization of operations into equivalence > > classes to the policy writer. > > I don't see anything special here either. With a > plain capability-bit system, you could allow for > user-defined aliases that map to multiple bits. > In some random /etc config file: > > define ADMIN := FOO | BAR | BAZ
This doesn't effect the inflexibility of a single definition for domain transistion that's inherent in the capabilty system.
> Lack of granularity is an implementation detail. > (Blame the SGI folks that wouldn't listen to me.) > Lack of granularity is not a design flaw.
It's a design flaw. More bits won't help. There's an important missing piece...credentials for both subject and object. Both of which can be dynamic, and differ per subject's view of an object.
> What I'm looking for: > > 1. configure the kernel by ... > 2. ensure that /bin/foo runs early in boot > 3. put "blah blah blah" in /etc/foo.conf > > That is, is there a small set of simple config files > and binaries that I could just slap onto an existing > system to ensure that a particular app is granted an > extra capability bit? > > If yes, then the ugly old-Oracle hack is not needed.
Nearly. There's the minor issue that execve() clears that bit more agressively than desired for non-root processes. Otherwise pam can do it with pam_cap. Which is all we're trying to fix here.
thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - 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/
| |