lkml.org 
[lkml]   [1999]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: file effective and process inheritable mask
    Date
    Y2K writes:
    > On Fri, 23 Apr 1999, Albert D. Cahalan wrote:

    >> The two most important extensions IMHO are:
    ...
    >> 2. The ability to mark an executable with the capabilities that were
    >> known to the setup tool. The kernel can use default values for any
    >> bits that are not listed. This lets kernel developers add new bits
    >> for traditionally unprivileged operations and lets them split old
    >> bits into more fine-grained sets of bits.
    >
    > How about CAP_LINUX_RESERVE_NORMAL_0 through CAP_LINUX_RESERVE_NORMAL_15
    > being defined for future caps which are new caps that presently availible
    > to everyone even non-root ones.

    How many is enough? I do not think we should reserve a particular number
    of slots. Also, that only covers the first problem.

    Let's imagine that it is 2003, Linux 3.0 is out, and everybody is using
    capabilities. Someone decides to split CAP_DAC_READ_SEARCH into less
    powerful components CAP_DAC_SEARCH and CAP_DAC_READ.

    Do you change the meaning of an existing bit, or do you end up with
    all three capabilities? If you have all three, how do they interact?
    If you change the meaning of an existing bit, stuff will break.

    If there is a "known set" fK associated with the file, it is safe to
    redefine the old bit. New kernels will know that the executable does
    not define the new bit, so they can set it equal to the old bit.

    >> After those two, I think it would be nice to allow configurations that
    >> are halfway between traditional behavior and the draft. One could let
    >> the more harmless capabilities (resources, read access...) be passed
    >> to child processes automatically, while enforcing the draft behavior
    >> for more destructive capabilities.
    >
    > Thats easily done and won't even break the draft just define the default
    > fI to be pP&(CAP_LINUX_RESERVE_NORMAL_0 | ...
    > |CAP_LINUX_RESERVE_NORMAL_15) for unmarked executable files.
    > you might just save yourself some trouble and say fI=pP ;->

    One (or both) of us doesn't understand the other I think.
    What I propose could work like this:

    1. The kernel calculates the draft capabilities. (call them d_pP, etc.)
    2. The kernel calculates old-style values too. (call them o_pP, etc.)
    3. The kernel has /proc-configurable masks. (call them p_pP, etc.)
    4. This is done:

    pP = (o_pP & p_pP) | d_pP;

    When the mask is 0, we get draft behavior. When it is full, capabilities
    can be inherited in a more normal manner.

    One might place these in p_pP:

    CAP_DAC_READ_SEARCH
    CAP_KILL
    CAP_NET_BROADCAST
    CAP_IPC_LOCK
    CAP_SYS_BOOT
    CAP_SYS_NICE
    CAP_SYS_RESOURCE

    These could be left out:

    CAP_CHOWN
    CAP_DAC_OVERRIDE
    CAP_FOWNER
    CAP_FSETID
    CAP_SETGID
    CAP_SETUID
    CAP_SETPCAP
    CAP_LINUX_IMMUTABLE
    CAP_NET_BIND_SERVICE
    CAP_NET_ADMIN
    CAP_NET_RAW
    CAP_IPC_OWNER
    CAP_SYS_MODULE
    CAP_SYS_RAWIO
    CAP_SYS_CHROOT
    CAP_SYS_PTRACE
    CAP_SYS_PACCT
    CAP_SYS_ADMIN
    CAP_SYS_TIME

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