Re: [rsbac] Thoughts on the "No Linux Security Modules framework" old claims

Amon Ott
2005-02-22T08:57:36Z

[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]

On Montag 21 Februar 2005 18:50, Casey Schaufler wrote:
>
> --- Lorenzo Hernández García-Hierro <lorenzo@gnu.org>
> wrote:
>
>
> > > There are cases where Linux DAC and MAC cannot
> > live happily together,
> > > because Linux DAC is too limited.
> >
> > Agreed.
>
> OKay, I'll bite. MAC and DAC are seperate.
> How is it that (the limited nature of) the DAC
> behavior makes a system with both unhappy?

Back in 2001/2002 (versions 1.1.2 and 1.2.0), I added DAC disabling
support first for the full filesystem, then for selected dir trees
and the converter tool linux2acl to RSBAC. I remember the actual
problem coming from a provider of virtual web servers, but I cannot
find the old mails. Too long ago.

We were not able to solve the given problem without changing the Linux
mode to 0777 (what means disabling DAC effectively). The reason to
add this feature was that the dir mode should not be changed to 0777,
because this would leave it completely unprotected with a non-RSBAC
kernel. Some programs even check Linux modes and refuse to run with
too many rights on their config files (what is usually a good idea,
but sometimes problematic), this is also a convenient workaround for
those.

Personally, I do not use the object based override myself, but rather
subject based override with additional Linux capabilities for
selected accounts and/or programs (which can be set with the RSBAC
CAP module, and which are dangerous because of LD_PRELOAD etc., if
the environment is not controlled). This means that I have to use MAC
configuration to restrict these users/programs afterwards, but that
is not the problem.

The moment you want to implement separation of duty for
administration, you will again and again run against Linux DAC
limits, because it only knows of one single admin. E.g. think of a
separate account doing user management and adding user dirs.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]