Re: Clarifications of LSM API

From: Valdis.Kletnieks@private
Date: Tue Jun 29 2004 - 13:53:02 PDT

  • Next message: Crispin Cowan: "Re: Clarifications of LSM API"

    On Tue, 29 Jun 2004 21:08:29 +0200, Tomas Olsson said:
    > Oops. Still fresh in this area.
    
    It's not an obvious in-your-face failure mode - it got explained to me several
    times before it really sank in.  
    
    The really ugly problems start when the module has enough expressiveness to be
    self-referential - and anything that is able to make a statement of the form
    "Thou shalt not mess around with the policy database" is probably
    self-referential enough to make having one such policy interesting, and more
    than one becomes "interesting" in the ancient Chinese curse sense.. ;)
    
    > With the chaining scenario above, would it be possible to avoid the problem
    > by differentiating between degrees of {dis,}allowing, letting FooLSM
    > explicitly override any rejections of such policy update attempts? This
    > starts to look ugly.
    
    Especially when the Anti-Foo rejects Foo's attempt to reject the rejection and
    the kernel deadlocks. ;)
    
    The problem is that with a chain of restrictive LSM's, if an early LSM rejects,
    it short-circuits and later LSMs never hear about the rejection.
    
    You *could* work around this issue by making things authoritative rather than
    restrictive, or running the entire chain, and saving each return code, and
    returning the maximum severity.  Unfortunately, both of those schemes have
    their *own* issues severe enough that we decided on restrictive ;)
    
    (And if this stuff doesn't make your brain hurt, you obviously don't
    understand it well enough yet... ;)
    
    
    



    This archive was generated by hypermail 2b30 : Tue Jun 29 2004 - 13:53:32 PDT