Making forward progress

From: Stephen Smalley (sdsat_private)
Date: Thu Aug 02 2001 - 09:05:02 PDT

  • Next message: Greg KH: "Re: 2001_08_01 patch against 2.4.7"

    We seem to be rehashing old issues without any real justification,
    and this is impeding forward progress on LSM.  Authoritative
    hooks were discussed, implemented, and discarded back in June.
    Moving DAC out of the base kernel was discussed and rejected.
    The ordering of the hooks with respect to DAC has been debated
    endlessly, but the arguments for putting the hooks first seem
    to have been effectively countered on this list.  And the
    "demise of simple assurance" is nothing new, definitely not
    a surprise to me, and presumably not a surprise to anyone
    who is actually implementing a LSM module.  Of course modules
    can modify the structures (and in some cases, this is quite
    desirable and necessary for implementing the desired security
    functionality).  Even without the explicitly passed structures,
    many modules will be inspecting the state of the current task
    (and in some cases changing it).
    I propose that we stay with our previous decisions on
    these issues, and make forward progress on LSM, e.g.:
    1) Move all hook calls after the DAC logic.
    2) Complete the capability module, as this is
    an important selling point for LSM.  This means
    moving the capability-specific logic from
    access, capget, and capset into the module,
    possibly moving the capability bits from
    linux_binprm and task_struct (and perhaps
    some of the network-related structures) into
    the security blobs, and fixing any remaining
    kernel references to the capability bits.
    3) Continue to define and implement 
    additional networking hooks based on our experiences 
    with using the current networking hooks for our various modules.
    4) Consider hooks for miscellaneous operations like
    nfsservctl, quotactl, bdflush, swapon, swapoff, stime/settimeofday,
    syslog, prctl (some of these had hooks defined in the SGI
    5) As previously recommended by Chris Wright:
    a) Review all current hook calls for placement, error handling,
    and parameters.  With respect to parameters, be sure that
    we aren't passing user space pointers or at least explicitly
    mark such parameters.
    b) Review the alloc/free hook calls for leaks.
    c) Place or remove any unused hooks.
    d) See if we can make the file system hooks consistent in their
    usage of struct vfsmount vs. struct super_block.
    Stephen D. Smalley, NAI Labs
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Thu Aug 02 2001 - 09:08:53 PDT