Quoting Stephen Smalley ([email protected]):
> On Wed, 2007-11-21 at 09:48 -0600, Serge E. Hallyn wrote:
> > Quoting [email protected] ([email protected]):
> > > +/*
> > > + * 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.
>
> 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.
Yeah, I was thinking it would be renamed to something smack-specific.
The concept of CAP_MAC_OVERRIDE is pretty general, but then users may
for just that reason expect the capability to also let them override
selinux and other capabilities.
For instance the capabilities equivalent to a CAP_MAC_OVERRIDE would
probably be CAP_SETPCAP, since it can be used to add capabilities back
into your inheritable set. But we wouldn't want to share one capability
for CAP_SETPCAP and CAP_SMACK_OVERRIDE. CAP_SETPCAP does let you regain
CAP_SMACK_OVERRIDE, but a process could have CAP_SMACK_OVERRIDE but be
denied CAP_NET_ADMIN for instance, or heck even CAP_DAC_OVERRIDE.
So short answer is: I agree :)
thanks,
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
