lkml.org 
[lkml]   [1999]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: file effective and process inheritable mask
    Date
    David L. Parsley writes:
    > On Sun, 25 Apr 1999, Albert D. Cahalan wrote:
    >> I propose two things:
    >>
    >> 1. per-bit selection of traditional and draft behavior
    >
    > erm, did I miss something here? Can you bring me up to speed on what this
    > is?

    The startup scripts write some data to a config file in /proc which
    determines which pP bits may survive an exec. You get the draft if
    none of the bits survive. This allows a compatibility vs. security
    tradeoff on a bit-by-bit basis.

    Example policy:
    Bits that only allow a DoS attack will survive an exec.
    Bits that provide more power do not survive.

    When I set up a system, I can let the real-time scheduling and memory
    locking abilities be passed across an exec. The ability to overwrite
    any file is much more dangerous, so I set that bit to draft behavior.

    >> 2. David's bit set that reduces pI content
    >
    > what about 3. fm=min caps to run else EPERM ?

    Oh yes, I forgot that one.

    > Just to be sure I'm not completely off base here, this is what it looks
    > like to me for current file cap sets (5 total):
    >
    > fP, bits explicitly raised in Permitted
    > fI, bits Inheritable from parent
    > fE, Effective bits initially set (yes, I agree we should go ahead and
    > include this full set)
    > fM, inheritable Mask, this adds security by restricting pI from always
    > passing unrestrained to the child
    > fR, (suggested nomenclature) Required capabilities; i.e., if the parent
    > process doesn't have the necessary pI for the child to run properly,
    > it fails with EPERM. This would occur, for example, when a normal
    > user tries to execute a system service which needs to inherit
    > certain bits to run, such as CAP_NET_BIND_SERVICE. This also has
    > the potential to protect from certain DoS attacks, and shortcuts
    > ugly error conditions.

    Yes, I like that name.

    > I'm curious, though, where everybody stands on setuid0 vs. ext2 bit.

    It is absurd to argue over this. The concept of "trust" should be totally
    independent of the features that rely on it. Filesystems should provide
    a VFS function to query for trust, and mount options to determine what
    attributes grant trust.

    I want to be able to trust _everything_ on a CD-ROM, or nothing at all.
    By default I want to trust setuid executables if and only if they are
    enabled anyway. The RSBAC patches could provide an alternate way to
    mark an executable as trusted, or could handle the data alone.

    mount -t ext2 -o trustroot,trustimmutable,trustuid=1 ...

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