Re: [RFC] LSM changes for 2.5.38

From: Christoph Hellwig (hchat_private)
Date: Tue Oct 01 2002 - 10:06:11 PDT

  • Next message: Chris Wright: "Re: [RFC] No more module_* hooks"

    On Fri, Sep 27, 2002 at 03:00:03PM -0400, Stephen Smalley wrote:
    > So you want to move the 'if (turn_on && !capable(CAP_SYS_RAWIO)) return
    > -EPERM;' from the base kernel into the security module's ioperm() hook
    > function, in addition to whatever additional logic the module may
    > implement?  [Assuming for the moment that we kept the ioperm() hook, even
    > though that isn't likely given its current lack of use and
    > architecture-specific nature].
    
    Exactly.
    > 
    > If so, what about the rest of the kernel access checking logic?  Do you
    > want all of the permission() logic pushed into the security module's
    > inode_permission() hook function?
    
    permission() switches into per-fs code.
    
    > Do you want the bad_signal() logic
    > pushed into the security module's task_kill() hook function?
    
    Only the capable() check.  Unless of course we make uid/gid checking optional.
    Which seems like a very bad idea given the mess even with just the current LSM
    hooks.
    
    > That kind of
    > change was considered and discussed on linux-security-module long ago, but
    > it will yield a very invasive patch for very little gain.  It also
    > requires cleanly separating all access checking logic from functional
    > logic (it is sometimes fairly intertwined) and determining exactly which
    > is which
    
    Umm.  Clean and nicely separated code is a lot of gain.  Making Linux's
    access clean instead of a lot more messy is a good think.  Much better than
    any feature addition.  (Unless, of course, you get paid for adding
    features..)
    
    
    > (e.g. is enforcing a read-only mount a security behavior or a
    > functional behavior?).
    
    For the kernel it's a functional behavior.  The administrator can chose
    to apply it for security reasons, but that's policy and thus not the
    kernel's issue.
    
    > 
    > > Show me a useful example that needs this argument.
    > 
    > Do you want every process that can use ioperm() to be able to access the
    > full range of ports accessible by that call?  If not, then you need
    > something finer-grained than CAP_SYS_RAWIO.  But as I said, we don't
    > presently use this hook, and it is architecture-dependent.
    
    Okay, this does actually makes sense.  Point taken.
    
    > 
    > > And WTF is the use a security policy that checks module arguments?  Do
    > > you want to disallow options that are quotes from books on the index
    > > or not political correct enough for a US state agency?
    > 
    > The LSM module_initialize hook is called with a pointer to the kernel's
    > copy of the relocated module image with the struct module header.  Hence,
    > the security module is free to perform whatever validation it wants on
    > that image prior to the execution of the init function.  But if the
    > criteria is that there must be a specific existing security module that
    > uses the hook, then this one will go away too.
    
    Yes, a hook without a intree user or at least a properly defined and
    available out-of-tree user is pointless.
    _______________________________________________
    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 : Tue Oct 01 2002 - 10:07:27 PDT