[rsbac] Re: Security patches

[Amon Ott]

On Samstag, 29. November 2003 10:05, Martin Pitt wrote:
> RSBAC has a lot of nice features and seems pretty well designed, but I
> do not use it because of the following:
> 
> - Security policies (ACLs etc.) are altered by calling command line
>   programs which modify binary files. I don't quite like that, I'm
>   more fond of keeping everything in a single human-readable
>   configuration file. But that is really a matter of taste.

To make it clear: Of course, no binary executables get touched, rather the 
persistent configuration is stored in fully protected binary files, which are 
thus safe from tampering.

> - It needs an extra account ("security officer" with UID 400) which is
>   a pretty bad idea IMHO. Since once you are SO (cracked/sniffed
>   password etc.), you can alter anything which seems like a giant
>   security risk to me.

You are only talking about the default configuration here, which is meant to 
get you going. Several of the implemented security models in the RSBAC 
framework support real separation of duty, e.g. with RC model you can 
distribute administration over many different roles for many different 
accounts.

Additionally, how would you become uid 400, if you are not allowed to setuid 
to this id? Or what would it help you, if the administrative rights got 
removed? This is an important difference to root - the system starts as root, 
so there is no way to protect the uid.

Now, in contrast, think of global configuration files: Once you are allowed to 
alter them, there is absolutely no control over what you do to them - this is 
what I call really dangerous. You cannot even remove the files, because you 
need them. So complete kernel level administration control is necessary for 
separation of duty, not some fancy thing.

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