Re: Making forward progress

From: Seth Arnold (sarnoldat_private)
Date: Fri Oct 05 2001 - 15:35:53 PDT

  • Next message: jmjonesat_private: "Re: [RFC] 2.4.11-pre4 patch"

    As a response to jmjones's recent question asking what is left, I felt
    it might be useful to look at Stephen's todo list from a little while
    back, and see just how much progress has been made since then. :)
    
    On Thu, Aug 02, 2001 at 12:05:02PM -0400, Stephen Smalley wrote:
    > 1) Move all hook calls after the DAC logic.
    
    Hmm. This appears to have been mostly done, as long as we allow some
    fudging on the definition of 'DAC'. :)
    
    > 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.
    
    Well, our capabilities module still looks an awful lot like the
    built-in capabilities support already in the kernel -- at least, it
    doesn't do anything with the security blobs. Whether or not recoding to
    support using the security blobs is a good idea or not, I just don't
    know. Stephen, now that you have had a week's experience or so with the
    second LSM-based release of SELinux, what do you think of the current
    capabilities module?
    
    > 3) Continue to define and implement 
    > additional networking hooks based on our experiences 
    > with using the current networking hooks for our various modules.
    
    I have no idea about progress on this front -- I don't know much about
    the Linux networking code. I know I would appreciate it if someone could
    assure me that the information available in the networking hooks allows
    for dropping packets, mangling packets?, modifying the security state of
    processes, based on rules including task information, interface,
    addresses used, etc...
    
    > 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
    > patch).
    
    Hmm. We've got nfsservctl, quotactl, bdflush, swapon, swapoff, syslog,
    and prctl covered. There isn't anything for the stime/settimeofday, not
    that I could quickly see anyway. (There is a capable() hook in
    do_sys_settimeofday, however...) Are there other miscellaneous
    operations that still need hooks? :)
    
    > 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.
    
    Good idea.
    
    > b) Review the alloc/free hook calls for leaks.
    
    Good idea.
    
    > c) Place or remove any unused hooks.
    
    Are there any hooks that people would like to nominate for removal? :)
    
    > d) See if we can make the file system hooks consistent in their
    > usage of struct vfsmount vs. struct super_block.
    
    Hmmm. There appear to be five uses of struct super_block and five uses
    of struct vfsmount. I don't know enough about the individual hooks to
    tell if this is fine, or indicitive of trouble.
    
    Not on this list, but also important -- higher level documentation. The
    SELinux team put together some decent enough high level docs; perhaps
    they should be reviewed again with the light of trying to provide more
    background/history/context for the project? (It might be the docs are
    fine enough as they are. :)
    
    Comments?
    
    _______________________________________________
    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 : Fri Oct 05 2001 - 15:37:44 PDT