lkml.org 
[lkml]   [2000]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Capabilities
    Andreas Gruenbacher wrote:

    >
    > I found this in the Irix B1 sources at <http://oss.sgi.com/projects/ob1>.
    > The cap_enabled global variable has one of the values CAP_SYS_SUPERUSER,
    > CAP_SYS_NO_SUPERUSER, CAP_SYS_DISABLED.

    --
    Yes, it is configurable. I think the code you are looking at is equivalent to the doc:
    ...
    You use these two privilege mechanisms [superuser and capability] to configure your IRIX system
    for one of two privilege environments:

    Augmented Superuser


    The augmented superuser privilege environment is a combination of the superuser-based privilege
    mechanism and the capability-based privilege mechanism. In this environment, an administrator
    logged in as root (user ID of 0) has unlimited, universally inherited privilege. Therefore, the
    administrator must be careful when executing commands to use only known commands and processes
    that are appropriate to the task at hand. Use of an untrusted command by the root user could grant
    unlimited privilege to a Trojan Horse program (a program designed to usurp access rights or privilege
    while performing an otherwise useful and apparently benign function).

    Note that while the superuser-based privilege mechanism grants root unlimited privilege, that
    privilege does not take the form of capabilities. Capability assignment and inheritance is not affected in
    any way by the user ID of the process.

    The augmented superuser privilege environment also employs the capability-based privilege
    mechanism. This allows nonroot processes to obtain privilege through specific assignment of
    inheritance of capabilities. The IRIX system does not automatically assign capabilities to users other
    than root (the system administrator) and auditor (the auditor). The IRIX system does, however, assign
    capabilities to certain nonadministrative commands and daemons. This allows fine control of privilege
    within these commands when they are executed by a nonroot process.

    The augmented superuser privilege environment most closely resembles the traditional UNIX privilege
    environment. It allows administration without specific concern for capabilities and capability
    inheritance. The advantage is simple administration and administrative flexibility. The disadvantage is
    the relative ease with which an administrator or system programmer can make a mistake that results
    in a security failure.

    No Superuser


    The no-superuser privilege environment contains only the capability-based privilege mechanism. In
    this environment the system administrator account is still root and the auditor account is still auditor,
    but root no longer derives privilege from its user ID. Instead, all privilege derives from capabilities.

    The no-superuser privilege environment yields the greatest protection from administrative error and
    Trojan Horse attack. It does, however, limit privilege to the set of commands authorized for
    capabilities, which may not include all commands that need privilege at your site. Also, it limits
    administrative flexibility by constraining administrators to commands that can inherit capabilities.

    The advantage of the no-superuser privilege environment is enhanced assurance that privilege will not
    be abused or usurped. The disadvantage is somewhat increased administrative complexity and
    decreased administrative flexibility.


    -
    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:56    [W:4.200 / U:0.124 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site