lkml.org 
[lkml]   [2009]   [Dec]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: A basic question about the security_* hooks
    > Well, taking a step back - what exactly is the motivation for making this
    > an LSM? Is it just to re-use the callsites?

    Yes. Alan Cox, referencing earlier versions of my patches, wrote:

    "This is a security model, it belongs as a security model using LSM."

    > I ask bc the API is in the prctl code, so the LSM
    > is conceptually always there, which is different from other LSMs.

    The goal is to provide a stupidly simple unprivileged per-process network
    isolation primitive which is broadly available "without jumping through hoops".

    (See http://cr.yp.to/unix/disablenetwork.html for a nice writeup.)

    I need a primitive like this to further my work on the OLPC Bitfrost security
    architecture and to further my more general work on advancing the state of
    sandboxing technology. (See sandboxing.org.)

    I'm willing to entertain pretty much any implementation or interface request
    which meets that goal and which implements the desired semantics.

    >>>> In particular, what would be worse about a kernel in which each security
    >>>> hook contained nothing but conditionally-compiled function calls to the
    >>>> appropriate "real" implementation functions with early-exit jumps on
    >>>> non-zero return codes?
    >>>
    >>> The problem is that composing any two security policies can quickly have
    >>> subtle, unforeseen, but dangerous effects.
    >>
    >> Have you any specific examples of problems that have been clearly averted
    >> by the current arrangement?
    >
    > If you look back over the archives of when I was pushing the LSM stacker
    > around 2005, there were several cases where just stacking capability and
    > selinux were problematic.

    Thank you for the pointers to your earlier work and for the work itself. We
    probably wouldn't be having this conversation if your work had been merged.
    Unfortunately, that happy event did not come to pass.

    Thus, returning to today: the most serious objection that I've heard so far
    about LSM stacking is that making it too "automatic" is likely to result in
    preventable security faults.

    For this argument to be valid, there *must* also be a second clause which
    states that the cost of the unknown security faults prevented by making
    stacking hard exceeds the cost of the known security faults which would be
    prevented by the additional security primitives that stacking, in any usable
    form, would permit. Otherwise, the sustaining the objection leads to a worse
    outcome.

    Now, given this argument, what do you actually think about systems that, like
    your work, enable stacking but which do so "less automatically", e.g. by
    hand-writing the implementations of the security_*() hooks like so:

    int security_socket_create(int family, int type, int protocol, int kern)
    {
    int ret = 0;

    #ifdef CONFIG_SECURITY_SELINUX
    ret = selinux_security_socket_create(family, type, protocol, kern);
    if(ret)
    goto out;
    #endif

    #ifdef CONFIG_SECURITY_TOMOYO
    ret = tomoyo_security_socket_create(family, type, protocol, kern);
    if(ret)
    goto out;
    #endif

    #ifdef CONFIG_SECURITY_SMACK
    ret = smack_security_socket_create(family, type, protocol, kern);
    if(ret)
    goto out;
    #endif

    #ifdef CONFIG_SECURITY_PRCTL_NETWORK
    ret = prctl_network_socket_create(family, type, protocol, kern);
    if(ret)
    goto out;
    #endif

    out:
    return ret;
    }

    This way, the behavior of the system is as predictable as possible, we can
    statically check for known unsafe configurations, manual tweaking of the order
    in which functionality is composed is possible, and security is fully
    "pay-as-you-go".

    Where is the flaw in this approach?

    Regards,

    Michael

    P.S. - I think I will write up some new patches for prctl_network based on this
    idea so that we can see what they look like.


    \
     
     \ /
      Last update: 2009-12-26 20:51    [W:0.030 / U:1.012 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site