Re: Frustrated with capabilities..

[Casey Schaufler]

David P. Quigley wrote:
> On Thu, 2008-08-28 at 13:48 -0400, Theodore Tso wrote:
>   
> > On Thu, Aug 28, 2008 at 05:45:34PM +0300, Markku Savela wrote:
> >     
> > > > From: Pavel Machek <pavel@xxxxxxx>
> > > >         
> > > > Yes, you need upcoming filesystem capabilities.  Binary may not
> > > > inherit capabilities unless filesystem flags permit that.
> > > >         
> > > I think this is wrong. Normal executables inherit uid/gid and
> > > supplementary groups by default. Why should capabilities be any
> > > different?
> > >       
> > Well, because that's not the what the POSIX draft specification (and
> > the rest of the Unix industry who were striving to meet the US
> > Department of Defense's "B2 by '92" initiative) ended up implementing.
> >     
>
> Minor nit. It was actually C2(Controlled Access Protection) by '92 which
> is mainly just DAC protections as opposed to B2(Structured Protection)
> which also included MAC policies and Sensitivity labels in addition to
> DAC protections

But the fun part was that the evaluation requirements for B1,
which fell in between C2 and B2 (the order from least secure to
most was D, C1, C2, B1, B2, B3, A1, and "Beyond A1") where so
close to those for C2 that everyone implemented B1, which did
include MAC policy in the form of Bell and LaPadula sensitivity.
The privilege model (now called capabilities, and you have to buy
me a beer to get the whole story) does not actually come in the
requirements until B3, although some people will argue that it
was intended they be included at B2. Even though no one even tried
a B3 and no one succeeded at B2 everyone did capabilities based
on one of the drafts or another.

Anyone who thinks that the capability scheme is wrong headed is
encouraged to read the P1003.1e/2c (withdrawn) DRAFT. It's on
the web in several places. You may end up still thinking it's
wrong, but at least you will have seen how the arguments got
hashed out.

And we're still not talking about the Jackson Hole meeting.


--
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/