Linux-kernel mailing list archive 2000-06,: Re: Capabilities

# Re: Capabilities

Theodore Y. Ts'o (tytso@MIT.EDU)
Fri, 11 Feb 2000 07:28:31 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Gregory Maxwell: "Re: Capabilities"
- Previous message: Pavel Machek: "Re: HSP Modem"
- Maybe in reply to: Peter Benie: "Capabilities"
- Next in thread: Chris Evans: "Re: Capabilities"
- Next in thread: Jesse Pollard: "Re: Capabilities"
- Reply: Chris Evans: "Re: Capabilities"

Date: Fri, 11 Feb 2000 11:11:01 +0000 (GMT)
From: Matthew Kirkwood <weejock@ferret.lmh.ox.ac.uk>

> [0] My thinking is somewhat slow today, but as I recall the
> fs caps implementation wants to include all three sets,
> yes?
>
> In the later POSIX drafts, I believe the fs capability sets have been
> dropped down to two, "allowed" and "forced".

That makes a lot of sense from a comprehensibility standpoint :-)

If process has CAP_FOO-p, will it get EPERM (EACCESS?) if it tries
to exec() a binary with that capability "forced"?

Think of the "forced" capability bit set as the same as the setuid bit.
It causes the program to gain that privilege upon being exec()'ed.

The "allowed" capability bit set is the set of capabilities which the
program as allowed to *inherit* from the previously exec'ed image. This
means that by default, once you have this capability installed, setuid
inheritance doesn't work anymore by default!

If you install a normal program, both capability bitsets are NULL, which
means that if that program is run by a "root" shell, it doesn't inherit
any privileges from the privileged shell program. This is actually a
good thing, as it means you can't run random programs that weren't
designed to be security conscious (say, like gcc) from a root shell and
expect them to be able to violate discretionary access control on
filesystems.

Unfortunately, this is very different from the traditional model, and so
sysadmins I suspect won't like this model very much. Configuring such a
system will also be contentious, since there will be big arguments about
which commands "the privileged user" should be allowed to run and still
have privileges. For example, should "emacs" be allowed to inherit any
privileges? (If not, the emacs can't be used to edit system
configuration files that are owned by some other user, like daemon,
unless the appropriate sysadmin groups are set up. But if it is allowed
to inherit privileges, you can do so much damage in emacs due to a
surprise emacs lisp file in your load-path, it isn't funny.)

- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Gregory Maxwell: "Re: Capabilities"
- Previous message: Pavel Machek: "Re: HSP Modem"
- Maybe in reply to: Peter Benie: "Capabilities"
- Next in thread: Chris Evans: "Re: Capabilities"
- Next in thread: Jesse Pollard: "Re: Capabilities"
- Reply: Chris Evans: "Re: Capabilities"