lkml.org 
[lkml]   [2000]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Capabilities
    Khimenko Victor wrote:
    >
    > [a lot of strange things]

    There seems to be some confuson about what Capabilities are, and how they are
    related to SUID binaries and filesystems.


    - A process is associated with the three sets of capabilities Inheritable,
    Permitted and Effective (I, P, E). It may temporarily suspend capabilities, and
    permanently drop capabilities. It also controls which capabilities are inherited
    by child processes.

    - Binaries should also be associated with the same three sets of capabilities
    (If, Pf, Ef). This is not yet implemented, which is why we don't yet have a more
    ``Trusted Linux''. When a binary is exec()ed, the new process should get the
    following capabilities (Posix 1003.1e DS17; X is an implementation defined
    value):

    (I1, P1, E1) = (I0, (Pf & X)|(If & I0), Ef & P1)

    A child process after exec() may thus have fewer or more capabilities than its
    parent process.

    - In the current Kernel, root is omnipotent. Before Capabilities, root was grant
    everything based on its uid. With the current implementation of Capabilities,
    SUID root binaries get full capabilities from exec(). (Capabilities may still be
    dropped, but the next SUID root binary will again be omnipotent).

    - What we really want for ``Trusted Linux'' is something else. Root should not
    be treated differently based on its uid. The capabilities of a new process
    should only be derived from the Inheritable set of the parent process, and the
    capabilities of the binary.

    - Once we have file-based capabilities, we can implement that. Here, the idea I
    posted before (which was shamelessly stolen from another OS) can be used. The
    kernel boots in ``non-trusted'' mode; SUID root binaries get all capabilities. A
    process in the init scripts then switches the system into ``trusted'' mode.
    After that, SUID root binaries are treated no different anymore.

    Switching to ``trusted'' mode is a system-wide decision, and is not filesystem
    based. Switching could be one way, or it could be ruled by a capability (if
    people really think it's necessary to switch back to ``non-trusted'' mode). In
    the latter case, that capability could still be disallowed on filesystems (see
    the X mask), so dropping that capability in all running processes would still
    give a high level of trust.


    For those who don't know yet, Posix 1003.{1e,2c} Draft Standard 17 is freely
    available at <http://www.guug.de/~winni/posix.1e/download.html>.


    Hope my confused words are still helpful.


    Regards,
    Andreas

    ------------------------------------------------------------------------
    Andreas Gruenbacher, a.gruenbacher@computer.org
    Contact information: http://www.bestbits.at/~agruenba

    -
    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:0.023 / U:0.128 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site