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