On Wed, 14 Apr 1999 17:21:44 +0200 (CEST), Ingo Molnar
<mingo@chiara.csoma.elte.hu> said:
> On Tue, 13 Apr 1999, Horst von Brand wrote:
>> The whole idea of capabilities is to get rid of all-powerful users, to
>> split the root powers among several people where _nobody_ has all
>> powers. Any scheme that keeps a root of some sort is broken.
> no. This is a misconception. The point is to reduce the power of actually
> executing security-relevant code, thus reduce the chance of a system
> compromise. Having some sort of (mostly inactive!) super-user around in
> the migration period is not at all broken.
That is somewhat inaccurate and misleading. The whole point of
capabilities *is* to make privileges independent of account
management, and part of that is to remove automatic association of
privileges with any one user account. As you note, a recommendation
that we preserve the super-user account is really only valid as a
temporary migration helper.
> The point is to get rid of random setuid root binaries (ping,
> traceroute, etc.) and system daemons (klogd, syslogd, lpd, etc.)
> executing with full system priviledges.
It is much more than that: it is to prevent privileges leaking, so
that bugs in these daemons do not compromise the security of other
parts of the OS.
> A considerable percentage of those binaries needs only a small
> subset of system priviledges. We do _not_ want to remove the
> administrator, that is a different task.
Sure, but that misses the point: we _do_ want to keep an
administrator. We do _not_ want the administrator account to have
full privileges.
In a capabilities environment, the way the admin account gains
privileges is through the filesystem, not through any privileged
accounts in the kernel. Typically you will have a set of utilities
with extra privileges enabled in them somewhere on the filesystem, and
only the admin accounts will have execute access to those utilities.
For example, you might have a shell binary with full privileges
enabled: that shell would be executable only by the admin account (not
necessarily root). You might have a shell with fewer privileges
enabled, but owned by (and executable by) the whole admin group, or
utilities executable by the operator group.
So you still have admin users: in fact, you can have multiple admin
users and groups, each with different levels of privilege. However,
the uids and gids themselves are not automatically privileged in the
kernel.
--Stephen
-
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/