Re: [BK PATCH] LSM changes for 2.5.59

From: Stephen D. Smalley (sdsat_private)
Date: Wed Feb 05 2003 - 07:00:23 PST

  • Next message: Christoph Hellwig: "Re: [BK PATCH] LSM changes for 2.5.59"

    Christoph Hellwig wrote:
    > Of course that needs further changes!
    > 
    > (a) actually implement that field, and
    > (b) change the prototype of the hook to int (*sysctl)(int op, enum sensitivity);
    
    No.  If one were to add such a field, then it would be accessible
    through the ctl_table structure that is already passed to the hook.
    You would not replace the ctl_table parameter with the kernel's
    sensitivity hint, since the security module must be able to make its
    own determination as to the protection requirements based on its
    particular security model and attributes.  If you only pass the
    kernel's view of the sensitivity, then you are hardcoding a specific
    policy into the kernel and severely limiting the flexibility of the
    security module.  Since the kernel's hint is necessarily independent of
    any particular security model/attributes, it will only provide a
    coarse-grained partitioning, e.g. you are unlikely to be able to
    uniquely distinguish the modprobe variable if you want to specifically
    limit a particular process to modifying it.  The existing hook
    interface does not need to change.
    
    Implementing a sensitivity hint field in the ctl_table structure would
    be trivial, but determining a set of policy-neutral hint values that
    capture important confidentiality, integrity, and functional
    characteristics and mapping the existing set of sysctl variables to
    those hint values is a longer term task.  The hook provides useful
    functionality now, apart from such hints, and should not need to wait
    on them.  In the short term, there may be a certain amount of
    duplication of information among security modules regarding sensitive
    sysctl variables, but that information can actually help to feed back
    into the process of determining the right general set of hint values
    necessary to support multiple security models and the mappings for
    the existing sysctl variables.
    
    --
    Stephen Smalley, NSA
    sdsat_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 Feb 05 2003 - 06:53:42 PST