Message-ID: <383368.46196.qm@web36605.mail.mud.yahoo.com>
Date:	Wed, 21 Nov 2007 09:21:04 -0800 (PST)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Stephen Smalley <sds@...ho.nsa.gov>,
	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	linux-kernel@...r.kernel.org, casey@...aufler-ca.com,
	chrisw@...s-sol.org, darwish.07@...il.com, jmorris@...ei.org,
	method@...icmethod.com, morgan@...nel.org, paul.moore@...com,
	LSM List <linux-security-module@...r.kernel.org>
Subject: Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree


--- Stephen Smalley <sds@...ho.nsa.gov> wrote:

> On Wed, 2007-11-21 at 09:48 -0600, Serge E. Hallyn wrote:
> > Quoting akpm@...ux-foundation.org (akpm@...ux-foundation.org):
> > > +/*
> > > + * There are not enough CAP bits available to make this
> > > + * real, so Casey borrowed the capability that looks to
> > > + * him like it has the best balance of similarity amd
> > > + * low use.
> > > + */
> > > +#define CAP_MAC_OVERRIDE CAP_LINUX_IMMUTABLE
> > 
> > Hey Casey,
> > 
> > note that 64-bit capabilities are now in -mm, so you could grab your own
> > capability.

A proposal with merit. I'll do it.

> Which brings up an interesting question - what to do with
> security-module-specific capabilities? CAP_MAC_OVERRIDE is specific to
> Smack - other MAC modules like SELinux won't honor it.  Maybe it should
> be CAP_SMACK_OVERRIDE.

But what about the MAC modules like Smack that do honor it?
They shouldn't be using a module specific capability, so
calling it CAP_SMACK_OVERRIDE isn't right because then the
SecureWare* port would have to introduce CAP_SECUREWARE_OVERRIDE
and bam, there go all your shiny new capability values. Further,
Smack isn't what's overridden by CAP_MAC_OVERRIDE, it's the
access control check, which is not the same thing at all at all.
SELinux ignoring CAP_MAC_OVERRIDE is perfectly within the
restrictive model of the LSM. If someone ported the Trusted
Irix 4 MLS system as an LSM** having CAP_MAC_OVERRIDE wouldn't
have to allow read of higher labeled files, as the policy on that
system never allowed that, even for privileged processes.

SELinux has every right to make it's own choices regarding how
it behaves relative to any specific capability because it is
allowed to restrict access in any way it sees fit. I think that
you would get in trouble if you changed the value of a capability
on a task within the LSM, because that will impact the "usual"
access checks, but I wouldn't expect to see you doing that.
SELinux has gone in a different direction on privileged operations
than capabilities, so it's not surprising that the two schemes
don't look like they're meshing very well in this case.

----
*  SecureWare was an MLS "kit". The MLS version of HP/UX was based
   on it, and the Macintosh version got the first ever CMW evaluation.
   SELinux took many of the same design approaches as SecureWare,
   and in it's early versions bore a somewhat frightening resemblence
   to the earlier system.

** Trix4 allowed a privileged process to write lower labeled files,
   but not read higher labeled files. That way any files that got
   created "by accident" were assured to be labeled at least as high
   as the data they contained.


Casey Schaufler
casey@...aufler-ca.com
-
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/

Powered by blists - more mailing lists