Valdis.Kletnieks@private writes:
> 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.
>
Well, I was thinking more of pure chaining, A() && B() && C().
> 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....
>
Oops. Still fresh in this area.
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.
The reason I asked, of course, is that I implemented a small jail-ish
LSM. It uses the process security blob, and hooks alloc/free. Then I found
that on some common distros, I lose. Due to existing LSMs in combination
with the current, restricting stacking.
Thanks
/Tomas (likes filters)
This archive was generated by hypermail 2b30 : Tue Jun 29 2004 - 12:09:23 PDT