Re: Hook function suggestion

From: Amon Ott (aoat_private)
Date: Fri Apr 20 2001 - 01:31:46 PDT

  • Next message: Amon Ott: "Re: Hook function suggestion"

    On Don, 19 Apr 2001 Steve Beattie wrote:
    > [reformatting for my sanity]
    > 
    > On Thu, Apr 19, 2001 at 11:42:49AM +0000, buddy wrote:
    > > As an example, needing root privileges in order to (un)load modules
    > > doesn't make me feel any safer, but apparently I'm more paranoid than
    > > you are. ;-) I'm worried about all those people relying on their LKM
    > > notifying them of a root compromise, and being owned all the same.
    > 
    > So we're in agreement that providing LSMs with the ability to mediate
    > the mechanisms for module (un)loading is necessary. I'm aware of three
    > different mechanisms for doing so, that we must provide hooks for:
    > 
    > 	-- the (init|create|delete)_module() syscalls 
    
    Essential and easy.
     
    > 	-- modifying /dev/(k)mem directly (which works even if you've
    > 	   compiled out support for loadable modules in your kernel, BTW).
    > 	   Thus we need to mediate file system accesses (so that an LSM
    > 	   can restrict access to /dev/mem) and in sys_mknod (so that
    > 	   an LSM can restrict the ability to create a character device
    > 	   that is equivalent to /dev/(k)mem).
    
    Let's not provide device protection via special files, but rather via device
    numbers. How can you ensure that e.g. no fs is mounted with such a special file?
    
    I have good experience with using device numbers and types (block/char) as
    identification.
    
    /dev/(k)mem interception can easily be done in drivers/char/mem.c:open_opert(),
    without the special files pain.
    
    Also, please do not forget /proc/kcore!
    
    > 	-- other filesystem tricks that involve installing a non-LSM
    > 	   enabled kernel or deleting your LSM module that proper
    > 	   filesystem mediation should give the LSM module the ability
    > 	   to prevent.
    
    Except for the boot process, this is mostly file protection via standard access
    control.
      
    > This level of mediation could certainly be insufficient for stopping such
    > an attack; if so, please outline for the list why it is insufficient
    > and (if possible) suggest ways to prevent such things. The important
    > thing is to provide a security model the means (via mediation hooks) to
    > prevent such an attack, NOT guarantee that the model actually does so.
    > As examples, requiring root privs or CAP_SYS_ADMIN to (un)load are
    > security models that likely won't prevent such an attack -- but that's
    > a weakness of those models, and hopefully not of the framework that this
    > list produces.
    
    The mechanism must support this control. How it is done is the module policy's
    problem.
    
    Amon.
    
    _______________________________________________
    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 Apr 20 2001 - 01:41:05 PDT