Re: [PATCH] capabilites, take 2
From: Chris Wright
Date: Fri May 14 2004 - 16:12:51 EST
* Albert Cahalan (albert@xxxxxxxxxxxxxxxxxxxxx) 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.
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/