[rsbac] RSBAC vs. LSM / SELinux in 2.6.0-test

[Amon Ott]

On Sunday, 31. August 2003 19:45, Peter Busser wrote:
> At this moment there is a situation where the RSBAC patch and the Linux
> Security Modules patch bite each other. Trying to force both in the 2.4 
kernel
> is like going into a patching hell. It is simply not worth it.
> 
> For 2.6, you have LSM and the SE Linux module (which is only part of SE 
Linux
> I think, the biggest part resides in userland). And I have no idea how the 
2.6
> port of RSBAC is going to work (maybe Amon can comment on that?).
 
If the LSM and SELinux stubs are in the kernel, they will not clash with 
RSBAC during patch - the RSBAC patch will be against the official tree in any 
case, with or without SELinux.


Based on this current discussion, I will express some of my thoughts about 
LSM / SELinux vs. RSBAC.

As far as I am concerned, some important problems in the LSM design (only 
partly solved by SELinux) are that

- it not by itself allows to register several functions at the same stub, so 
modules have to implement a stacking and Meta decision algorithm by 
themselves. There is a stacker helper module, but this does not seem to be 
included by default.

- it is *very* low level, exporting and exposing kernel internal data 
structures directly to the registered functions and without any abstraction. 
You will have to #ifdef for the kernel version inside these functions, 
bringing back the kernel version dependency which had been one goal to avoid 
and which is mostly avoided in the RSBAC framework.
(I remember Steven Smallay arguing that RSBAC's exposing only *some* of these 
structures without accessing them in the decisions was real bad.)

- there is no generic syscall interface for administration. The once existing 
sys_security has even been removed (!), because you can reimplement all 
administration logic with pseudo files in /proc or a separate filesystem 
(like SELinux does), thus getting back to file access control lying in the 
way. Such a, quite SELinux specific, interface is in /proc/pid/attr to read 
process attributes, see recent dicussion at the LSM list with Philippe Biondi 
of LIDS.
There had been long discussions why one more syscall added to over far over 
200 would not be acceptable to keep, correct me if I got the focus wrong.

- LSM does not have an infrastructure for attribute management. Each module 
still has to reinvent the wheel for subject and object attributes, not even 
talking of persistent storage. The only thing available is a void pointer at 
the most important (kernel version specific) structures, which, again, has to 
be shared by all registered modules (!).

- the post calls (notification calls in RSBAC) are rare, although they should 
have been there in most cases, and at least partly miss the original 
arguments to the controlled functions. This can be mended in later LSM 
versions, though - with another bunch of #ifdefs for the LSM version...

Please do not get the idea that I disagree with all the work done for LSM. It 
is just that in my opinion an access control framework for Linux should look 
very different. My limited amount of time (I do not get paid for RSBAC 
development) forbid to closely follow the LSM implementation, so I refrained 
from arguing around after stating my general opinion.

The big LSM problem was to be accepted by the main stream kernel, which more 
focused on functionality and speed than well designed security. The LSM team 
decided to take what they could get despite the disadvantages, and so far I 
have decided to do what I believed to be better design, even it it would 
never be part of the official kernel.

SELinux is so deeply integrated with LSM, that they even had to remove some 
network access control, which they previously believed to be necessary.

I am not going to remove anything from RSBAC believed to be important, unless 
there is a very good reason for it. Some extensions are impossible with LSM 
by design, e.g. the partial tree Linux DAC disabling, the symlink redirection 
or the secure delete functionality. This means that there will be an RSBAC 
patch for a long time to go, it will only become slightly smaller by moving 
some functionalily from the patch to the registered LSM functions.

So far, I have not decided wether to provide LSM stacking logic in RSBAC, 
this might come later. A restricted, LSM-only RSBAC version looks quite 
unlikely for the near future, because too many important interfaces are 
missing. The final picture will come after I finished the port.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22