Re: [RFC] [PATCH] file posix capabilities

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

Relevant Pages

  • Re: [RFC] [PATCH] file posix capabilities
    ... forward/backward compatibility. ... Or do you really mean add a cap name to the structure? ... Do you run it without any capabilities at all? ... with less privileges than it expects and opening up a security hole). ...
    (Linux-Kernel)
  • [PATCH 13/20] ceph: capability management
    ... capabilities granting clients permission to read and/or write to OSDs ... In the case of an EXCL or WR capabilities, the client is ... the MDS will revoke the conflicting client capabilities. ... * Generate readable cap strings for debugging output. ...
    (Linux-Kernel)
  • [PATCH 14/21] ceph: capability management
    ... capabilities granting clients permission to read and/or write to OSDs ... In the case of an EXCL or WR capabilities, the client is ... the MDS will revoke the conflicting client capabilities. ... * Generate readable cap strings for debugging output. ...
    (Linux-Kernel)
  • POSIX1.e capabilities in ou-o-the-box distributions
    ... I am looking into the Linux Capabilities, which have been part of the ... cap CAP_NET_ADMIN = effective SET, permitted SET, inheritable SET ...
    (comp.os.linux.development.system)
  • [PATCH 13/20] ceph: capability management
    ... capabilities granting clients permission to read and/or write to OSDs ... In the case of an EXCL or WR capabilities, the client is ... the MDS will revoke the conflicting client capabilities. ... * Generate readable cap strings for debugging output. ...
    (Linux-Kernel)