Re: [PATCH] capabilites, take 2
From: Albert Cahalan (albert_at_users.sf.net)
Date: 05/14/04
- Previous message: Benjamin Herrenschmidt: "Re: [4KSTACK][2.6.6] Stack overflow in radeonfb"
- In reply to: Chris Wright: "Re: [PATCH] capabilites, take 2"
- Next in thread: Chris Wright: "Re: [PATCH] capabilites, take 2"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Chris Wright <chrisw@osdl.org> Date: 14 May 2004 15:32:32 -0400
On Fri, 2004-05-14 at 17:11, Chris Wright wrote:
> * 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.
That's what much of the document went on about. The
rest of the document was mostly generic MAC concepts.
> > > 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.
Sure. I already noted this.
> > 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.
There is no meaningful object.
subject: process 12345
object: ??????
operation: lock memory
For a few capability bits, there is a meaningful object
and you could use SELinux in place of the capability bits.
For most of the capability bits, this is not the case.
> > 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.
Stephen Smalley suggested that SELinux could take the
place of our capability bits. So I'm asking how you do
that, using the most minimal SELinux config.
If he really has a way, then there is no need to change
the execve() behavior in the Linux 2.6.x kernels.
Perhaps we just need an LSM hook to re-add the capability
bit after execve() drops it. That's a tiny change that
doesn't affect any existing system.
-
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/
- Previous message: Benjamin Herrenschmidt: "Re: [4KSTACK][2.6.6] Stack overflow in radeonfb"
- In reply to: Chris Wright: "Re: [PATCH] capabilites, take 2"
- Next in thread: Chris Wright: "Re: [PATCH] capabilites, take 2"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
