lkml.org 
[lkml]   [1999]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:51    [W:3.508 / U:0.768 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site