Re: Clarifications of LSM API

From: Valdis.Kletnieks@private
Date: Tue Jun 29 2004 - 08:34:30 PDT

  • Next message: James Morris: "Re: Clarifications of LSM API"

    On Tue, 29 Jun 2004 09:41:30 +0200, Tomas Olsson said:
    
    > To me the possibiliy of having several, specialized modules called for
    > access checks in the order they were loaded, seems very useful. If one
    > denies, the operation is denied. That way, any LSMs could coexist without
    > the need for stacking implementation in every one.
    
    Well... yes and no.  The problem is that to show correctness of stacking 2
    LSM's A and B, you have to show that not only do the security functions A() and
    B() work, but that at least one of the 2 function compositions A(B()) or B(A())
    are also correct.
    
    Now, it's pretty easy to show (for instance) that the fairly small LSM that I
    would have under a stacker would co-exist with Serge's Jail LSM without many
    issues.  I could easily trim mine down to *only* do some hardening of certain
    operations within a directory that's *both* wold-writable *and* mode +t, while
    Jail only affects chroot'ed processes.  It doesn't take much work to show that
    any corner case (a chroot'ed process doing unsafe things in /chroot/tmp? ;)
    probably deserved to lose anyhow, and that if nothing else, you still retain
    the ability to keep control of your system...
    
    > With every LSM restricting access, security wouldn't be any lower (given
    > that capable() is handled in a sensible way), right? Seems like a fairly
    > clean patch.
    
    It's *not* just capable(). That's merely the nose of the camel
    poking into the tent.. ;)
    
    The problem arises when you consider a more complicated LSM such as SELinux.
    It's *quite* conceivable that you could end up with the following failure
    scenario:
    
    1) Stack SELinux
    2) Stack another LSM (say FooLSM) that provides a similar ACL capability.
    3) SELinux's policy rejects attempts to update FooLSM's policy/ACL.
    4) FooLSM's policy rejects attempts to update SELinux policy.
    5) SELinux won't let you turn FooLSM off because it requires an ioctl()
       not permitted, and FooLSM rejects the call to turn SELinux off....
    
    (You think this is implausible?  Consider the number of people who have been
    admitted to the sysadmin clinic with firearms wounds on their lower extremities
    because they booted an enforcing SELinux kernel on an unlabeled root filesystem
    - and you end up needing the power button because /sbin/shutdown won't run
    anymore.... ;)
    
    But even that's a fail-safe scenario. Feel free to devise one where LSM-A and
    LSM-B end up hiding info from each other, resulting in a operation being
    allowed when it should have been denied if the LSM's had the data they
    needed....
    
    
    
    



    This archive was generated by hypermail 2b30 : Tue Jun 29 2004 - 08:34:54 PDT