Re: [RFC][PATCH] selinux: support 64-bit capabilities

[Casey Schaufler <casey@schaufler-ca.com>]

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

> 
> On Thu, 2008-02-07 at 08:03 -0600, Serge E. Hallyn wrote:
> > Quoting Stephen Smalley (sds@tycho.nsa.gov):
> > > 
> > > On Thu, 2008-02-07 at 11:04 +1100, James Morris wrote:
> > > > On Wed, 6 Feb 2008, Stephen Smalley wrote:
> > > > 
> > > > > 
> > > > > > +	switch (CAP_TO_INDEX(cap)) {
> > > > > > +	case 0:
> > > > > > +		sclass = SECCLASS_CAPABILITY;
> > > > > > +		break;
> > > > > > +	case 1:
> > > > > > +		sclass = SECCLASS_CAPABILITY2;
> > > > > > +		break;
> > > > > > +	default:
> > > > > > +		return -EPERM;
> > > > > 
> > > > > Should likely make this something like:
> > > > > 	printk(KERN_WARNING "SELinux:  unknown capability %d\n", cap);
> > > > > 	if (selinux_enforcing)
> > > > > 		return -EPERM;
> > > > > 	else
> > > > > 		return 0;
> > > > > 
> > > > > Then, if/when people introduce capabilities without updating SELinux,
> > > > > we'll get a warning but permissive mode will allow the operation to
> > > > > proceed.
> > > > 
> > > > Agreed, perhaps also suggest upgrading policy in the message.
> > > 
> > > Policy upgrade won't help in that case - it requires code changes to
> > > allow SELinux to deal with higher capabilities beyond its supported
> > > range (the printk here is in the default: case, where we've gone beyond
> > > CAP_INDEX() of 0 or 1, i.e. capability value >= 64).
> > > 
> > > Alternatively, possibly we could cause a build failure in some way if
> > > CAP_INDEX(CAP_LAST_CAP) > 1, and make the default case a BUG().
> > 
> > That sounds good.  And maybe add a comment near CAP_LAST_CAP pointing
> > out that it's only responsible for any new caps to be added to
> > security/selinux/include/av_perm_to_string.h
> 
> Well, I think we'd just insert a polite request there to send an email
> to the SELinux maintainers and/or the entire LSM list to notify all LSM
> maintainers that they need to deal with a new capability.

That wouldn't be a bad idea, maybe put something in Documentation, too.

> We don't
> really want people directly patching the generated headers though - we
> need to keep them in sync with policy (and avoid the Fedora fiasco with
> taking permissions that never got reserved upstream in policy).

Yes, patching generated headers is a bad idea.


Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.