Re: Maintaining LSM modules

From: Greg KH (gregat_private)
Date: Mon Apr 15 2002 - 08:56:54 PDT

  • Next message: Chris Wright: "Re: Maintaining LSM modules"

    Hi,
    
    I've thought a lot about this problem in the past few weeks, and even
    tried out a few different options, but in the end I think we should
    leave things as they are.  My reasoning behind this is below.
    
    
    On Mon, Apr 15, 2002 at 12:08:20PM +1000, Lachlan McIlroy wrote:
    > 
    > A recent post by Richard Offer sparked some thoughts about the problems 
    > of maintaining modules that use the LSM framework.
    
    First off, these are not unique problems.  All kernel interfaces have
    these same problems (however they are not usually dealing with so many
    different function pointers, which makes LSM a bit unique, but not that
    much.)
    
    > The current method of sanitizing a module during load only checks that 
    > there are no NULL pointers in the security operations structure.  What 
    > about old modules that have a smaller security operations structure 
    > which is immediately followed by non-NULL data?
    
    Then you built your module against a different kernel version.  No
    sympathy there :)
    
    > If the name, purpose, number or type(s) of arguments for any exisiting 
    > hook(s) are changed then a not-up-to-date module will still load but 
    > hooks could be called with misinterpreted purpose or number/type(s) of 
    > arguments causing a security hole or even a panic.
    
    If your security module is in the kernel tree, then the person who
    changed the interface, is usually responsible for fixing up your module.
    Also the compiler catches lots of these problems (name changes,
    parameter changes, type changes, etc.)
    
    If your security module is not in the kernel, then it is up to you to
    keep on top of things.  This is just like all other kernel interfaces
    work.
    
    > As new features are added to the kernel, new hooks are added to the 
    > security framework so module writers need to maintain module source for 
    > different kernel versions unless the new features are backported or 
    > support for forthcoming hooks is accounted for.
    
    Why maintain modules for old kernel versions?  If you are keeping your
    module outside of the kernel tree, then yes, this is a lot of work.  My
    advice would be to get your module accepted into the kernel :)
    
    > A version number on the security framework (as previously discussed) 
    > will help but will cause inconveniences - every time the security 
    > framework is updated all modules need to be modified and rebuilt even if 
    > the changes made to the security framework are not relevant to all modules.
    
    Version numbers are not acceptable, and do not help anything except for
    loading a module compiled against a old kernel into a new kernel.  And
    modutils already handles this issue and tries to keep you from doing
    this (yes it can be overridden, but you know you are doing something bad
    when you do it.)
    
    > Some approaches to solving these issues (if I'm not the only person 
    > concerned about them) are:
    > 
    > * Pre-allocate space for future hooks by using a large structure with 
    > fields marked as 'unused' or use an array of hooks similar to a system 
    > call table.
    
    No, adding "reserved" fields are useless.  No other in-kernel interface
    does this.  See the above reasons about old modules and new kernels for
    reasons why.
    
    > * The description (name, purpose, number/type(s) of arguments) of 
    > existing hooks must not change.
    
    Yes it will.  That is the joy/pain of Linux.  The internal kernel apis
    are allowed to change, and will change over time.  See the main
    flamefests on lkml for reasons for this.
    
    > * When the description of a hook is to be changed then a new hook is 
    > created and the old hook either remains active or is marked as disabled.
    
    No, see previous point.  The compiler is your friend here, and will
    catch any problems with arguments.  Just pay attention to the warnings
    you get from it :)
    
    > * New hooks are added only from available hook space.  Increasing the 
    > size of the security operations structure could be problematic if an 
    > older module was allowed to be loaded and the new hook(s) called.
    
    No, see my response to previous points about reserved space, and modules
    not matching the proper kernel version.
    
    > * Filling the hook structure/array with stub routines (not the dummy 
    > security profile) before allowing a module to register its own routines 
    > would ensure that all hooks are callable whether supported by the module 
    > or not.  The default behaviour of these stubs would probably be 'deny 
    > access'.
    
    This might be acceptable, just to cut down on the amount of work it
    takes for someone to create a module (look at the OWL-like modules, they
    contain a lot of empty hooks.)  A number of different proposals to
    handle something like this have been tried, and may be something that
    eventually gets implemented.  No other kernel api does this today, but
    due to the size of the number of functions the LSM interface has, this
    might be the reason to do something new.  The verdict is still out on
    this, and I'd like to see some feedback from other people here.
    
    > I'm just trying to make life easier for the maintainer ...
    
    To quote Dave Jones, "Maintaining is hard, let's go shopping."
    
    thanks,
    
    greg k-h
    _______________________________________________
    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 : Mon Apr 15 2002 - 09:59:56 PDT