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
