Re: [RFC] [PATCH] file posix capabilities

["Serge E. Hallyn" <serge@hallyn.com>]

Quoting Nicholas Miell (nmiell@comcast.net):
> On Mon, 2006-08-14 at 21:29 -0600, Eric W. Biederman wrote:
> > "Serge E. Hallyn" <serue@us.ibm.com> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/