Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Thu, 15 Apr 1999 15:02:39 +0100 (BST) | Subject | Re: caps in elf, next itteration (the hack get's bigger) |
| |
Hi,
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/
| |