Quoting Nicholas Miell ([email protected]):
> On Mon, 2006-08-14 at 21:29 -0600, Eric W. Biederman wrote:
> > "Serge E. Hallyn" <[email protected]> writes:
> >
> > > In fact my version knowingly ignores CAP_AUDIT_WRITE and
> > > CAP_AUDIT_CONTROL (because on my little test .iso they didn't exist).
> > > So a version number may make sense.
> > >
> > >> So we need some for of
> > >> forward/backward compatibility. Maybe in the cap name?
> > >
> > > You mean as in use 'security.capability_v32" for the xattr name?
> > > Or do you really mean add a cap name to the structure?
> >
> > I was thinking the xattr name. But mostly I was looking
> > for a place where you had possibly stashed a version.
> >
> > Thinking about it possibly the most portable thing to do
> > is to assign each cap a well known name. Say
> > "security.cap.dac_override" and have a value in there like +1
> > add the cap -1 clear the cap. That at least seems to provide
> > granularity and some measure of future proofing and some measure of
> > portability. The space it would take with those names looks ugly
> > though.
On the one hand, there shouldn't be many executables with capabilities
so even a horrendous abuse of disk space isn't so bad, but on the other
hand, yes, it'd be a horrendous abuse of disk space :)
> > The practical question is what do you do with a program that
> > was give a set of capabilities you no longer support?
> > Do you run it without any capabilities at all?
> > Do you give it as many capabilities of what it asked for
> > as you can?
> > Do you complain loudly and refuse to execute it at all?
> >
> > What is the secure choice that least violates the principle of least surprise?
>
> Make it an arbitrary length bitfield with a defined byte order (little
> endian, probably). Bits at offsets greater than the length of the
> bitfield are defined to be zero. If the kernel encounters a set bit that
> it doesn't recognizes, fail with EPERM. If userspace attempts to set a
> bit that the kernel doesn't recognize, fail with EINVAL.
>
> It's extensible (as new capability bits are added, the length of the
> bitfield grows), backward compatible (as long as there are no unknown
> bits set, it'll still work) and secure (if an unknown bit is set, the
> kernel fails immediately, so there's no chance of a "secure" app running
> with less privileges than it expects and opening up a security hole).
Sounds good.
The version number will imply the bitfield length, or do we feel warm
fuzzies if the length is redundantly encoded in the structure?
> OTOH, everybody seems to have moved from capability-based security
> models on to TE/RBAC-based security models, so maybe this isn't worth
> the effort?
One day perhaps, but that day isn't here yet. People are still using
setuid (see /sbin/passwd), so obviously they're not sufficiently
comfortable using *only* TE/RBAC.
-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]
