Direction of the mailing list/effort

From: Stephen Smalley (sdsat_private)
Date: Wed Apr 18 2001 - 13:49:27 PDT

  • Next message: Casey Schaufler: "Re: Direction of the mailing list/effort"

    I'm concerned that the direction of this mailing list/effort is rather
    far from what was originally requested by Linus.  Let's back up for a
    moment to Linus' original message.  
    
    1) Linus said that he wants a truly generic solution.  Now, I could
    argue that SELinux already provides a truly generic solution - it is
    already the case that SELinux cleanly separates policy from
    enforcement, and it can support a wide range of security policies.
    The architecture of SELinux has been experimentally validated in
    several prior prototype systems (Flask, DTOS, and DTMach), and several
    formal studies have been performed of its security, assurability, and
    flexibility.  The RSBAC folks could probably make some similar claims
    for their system, since their work draws from a paper by LaPadula
    based on Abrams' Generalized Framework for Access Control.  So we have
    two working example systems today that go a long way toward this goal
    and that are based on a significant amount of research and
    development. I understand that neither SELinux nor RSBAC provide quite
    the style of interface that Linus wants.  But if you want a truly
    generic solution, it makes more sense to convert the SELinux and/or
    RSBAC interface to meet Linus' style than to start from scratch and
    have to re-argue about every hook.
    
    2) Linus said that he would be willing to entertain the notion
    of a large number of hooks in the kernel (he mentioned the number
    140 without objection in his first message, and 200 in his
    second message).  That suggests that rather than being minimalist
    in developing our set of hooks, we can indeed take the set of
    code insertion points in existing systems like SELinux and RSBAC
    and define hooks based on them.  That allows us to provide
    comprehensive and flexible security and lets us leverage
    all of the prior research and development that has already
    gone into SELinux and RSBAC.
    
    3) Linus also said that he would be willing to accept security IDs 
    into a number of kernel data structures. Security IDs, if you're not 
    familiar, are a policy-independent data type for security labels 
    already used in SELinux.  We already know what data structures need 
    security IDs for SELinux, since it is already implemented.  RSBAC
    used a different approach (using separate mappings for binding
    labels to subjects and objects), but they could probably easily 
    generate a list of the data structures they would like to be able
    to directly tag.  
    
    Based on Linus' message, I would think that the natural way to respond
    would be for projects like RSBAC and SELinux (and possibly others) to
    (preferably cooperatively but if necessary competitively) define the
    set of hooks that they would need based on their current code
    insertion points and to move their existing implementations behind
    these new hook interfaces.  Since both RSBAC and SELinux are already
    quite general, I doubt that we would have any problem with
    implementing POSIX.1e capabilities, LIDS, LOMAC, SubDomain, CryptoMark
    and other schemes behind those same hooks.  This approach will produce
    a truly generic solution that is both flexible and secure and that can
    satisfy all of the projects.  There is no reason to think that Linus
    will reject it, since he has expressed a willingness to consider a
    large number of hooks and since he wants a truly generic solution.
    
    --
    Stephen D. Smalley, NAI Labs
    ssmalleyat_private
    
    
    
    
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Wed Apr 18 2001 - 13:52:12 PDT