Re: module's use of security_ops

From: Chris Wright (chrisat_private)
Date: Fri Jun 08 2001 - 10:01:55 PDT

  • Next message: sarnoldat_private: "Re: module's use of security_ops"

    * jmjonesat_private (jmjonesat_private) wrote:
    > On Thu, 7 Jun 2001, Chris Wright wrote:
    >
    > No major objection, but could we preserve some of the "obscurity factor"
    > by creating a 
    > 
    > get_security_ops()
    > 
    > call, which passes to the module and could return -EPERM?  My thinking is:
    > 
    > * Drivers, etcetera, could access it if it was within module policy,
    
    I assume "module policy" means an LSM policy.  How do you propose to
    identify the non-LSM module asking for the security_ops struct?  By
    module name...hi I'm the really safe 3c509 driver can I please have the
    security_ops?  This can be trivially forged.
    
    > * It reduces the exposure of the structure to areas of the kernel+modules 
    >   where it may not be necessary.
    > 
    > By exposing it entirely, you bypass the sanity and "locking" effects 
    > of the current code, don't you?  Also, exposing it globally allows a 
    > "bypass security crack" to live in ANY loadable entity, doesn't it?
    
    No, by exporting the symbol you are not undermining organized access to
    the struct.  Anyone at anytime could start walking through the task list
    witout locking it and changing nice values, and pids, and uids, and...
    The kernel is functional not because there are things developers can't
    do, but things developers should do and have the tools to use (i.e. lock
    before accessing).  A module can scribble anything it wants anywhere.
    We can't stop this, and not exporting the security_ops struct looks like
    it actually impedes a non-lsm module from being able to _use_ the
    security provided by a lsm module.  This seems counter productive.
    
    > Yes, I have been told that "once you can install a module you're pretty 
    > much lost anyway", but a "policy" was in force that prevented it (one 
    > primary registration only) that is now lost.
    
    Kernel deadlocks can be avoided by convention that is not strictly
    enforced.  For example, when acquiring two locks grab them in a
    consistent order.  This is not strictly enforceable...even if there is
    helpful function that always grabs the locks in the same order...a
    malicious or ill-informed developer could not use the helper function
    and grab the locks in what ever order they so feel.  Same goes here.
    This does not mean registration policies are lost...it just means that
    to be a good little lsm you have to play by the recommended rules.
    
    -chris
    
    _______________________________________________
    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 Jun 08 2001 - 10:06:39 PDT