linux-kernel - Re: Frustrated with capabilities..

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1220019601.2627.129.camel@moss-terrapins.epoch.ncsc.mil>
Date:	Fri, 29 Aug 2008 10:20:01 -0400
From:	"David P. Quigley" <dpquigl@...ho.nsa.gov>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	Theodore Tso <tytso@....edu>, Markku Savela <msa@...h.iki.fi>,
	Pavel Machek <pavel@...e.cz>, linux-kernel@...r.kernel.org
Subject: Re: Frustrated with capabilities..

On Thu, 2008-08-28 at 21:47 -0700, Casey Schaufler wrote:
> 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@...e.cz>
> >>>>         
> >>>> 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.
> 

And one wonders why these certs aren't in use anymore ;)

Dave

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