[rsbac] LSM support removed and ported to 2.6.0-test9

[Amon Ott]

On Thursday, 30. October 2003 09:27, Peter Busser wrote:
> > > - Script to create auth cap setting script from syslog
> > 
> > Some time ago I wrote such a script in perl, see appendix - it reads the 
> > security-log and writes "auth_set_cap ... " commands to stdout.
> > It tries to guess where the actually used executable resides (searching 
in 
> > $PATH or in the --path specified on commandline) to write full pathnames 
in 
> > the auth_set_cap commands. If it doesn't find the executable that caused 
the 
> > AUTH deny, it adds a commented-out auth_set_cap command.
> 
> But you can do it even smarter. The RSBAC kernel code could add a AUTH cap
> record automatically. Every violation adds a new AUTH cap record.

I am adding an AUTH learn mode, which does this, because AUTH caps are easy 
and missing in default settings.
 
> The same can more or less be done for RC. After setting up roles and types, 
a
> lot of time is spent on getting the access vectors right. If access from a 
role
> to a type is denied, the kernel could add the corresponding access bit
> automatically. The only thing is, you have to setup roles and types before 
you
> do that and also properly assign types to the various objects in the system.

RC is much more difficult, because the automatic solutions will very often be 
far from optimal - e.g., wrong type at an object, or wrong role for a 
program, will lead to many unwanted privileges.
 
> The logic is simple, for every access violation, there is a setting missing.
> Add the setting and there is no violation anymore. And it guarantees that 
you
> provide no more access than is required.

Sorry, no, it does not guarantee that. One example: If a role needs a certain 
right to one single object of type A, it should not get the right to all 
objects of this type - instead, we need another type.

If roles or types are wrong, we can ruin the whole setup.

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