Re: Unix secuity and RSBAC ACL's

From: Amon Ott <ao@rsbac.org>
Subject: Re: Unix secuity and RSBAC ACL's
Date: Wed, 14 Mar 2001 09:38:59 +0100

Next Article (by Subject): Unreadable "Alberto Guglielmo"
Previous Article (by Subject): Unix secuity and RSBAC ACL's
Top of Thread: Unix secuity and RSBAC ACL's
Articles sorted by: [Date] [Author] [Subject]

On Die, 13 Mär 2001 john@mwk.co.nz wrote:
> As I understand it, unix perms are tested first, then RSBAC perms. Thhe
> result is the most restrictive set of permissions.
> 
> Thus to use ACL's for a file server you must put 777 on the directories then
> apply RSBAC ACL's.
> 
> The problem is that some programs, sendmail, procmail and likely many
> others, will test for security problems on directories.
> They cant know about RSBAC and decide that world and group writeable
> directories are a security failure.
> 
> Procmail wont execute your procmailrc in your home directory in this case.
> Sendmail complains also.
> 
> Is there any way of changing this so that where RSBAC ACLs and unix perms
> are applied, the RSBAC ACL's override the unix perms?

First of all, RSBAC ACLs are always active and applied, if the decision code
gets called. They might be inherited, but are always there. Even more, the
decision code does not even see where the permission vector for a subject comes
from - inheritance is part of the data structures. Only accumulation of user,
group and role rights is done in the decision code.

One solution would be to optionally disable Linux access control, with all
risks, while still returning the existing access bits on sys_access. However,
as you know, this is very dangerous, if RSBAC setup is not done very carefully.

We could misuse the DAC_override Linux capability etc. and simply set them for
marked programs, but this is also dangerous. Possibly a file attribute
'force_linux_caps' with a vector of caps, which is controlled by all modules.
The advantage is that it only gets used, if RSBAC is active.

The Linux setuid flag is probably also checked by the programs. If not, you
could use that one for now. Bad solution if you ever plan to go back to kernels
without RSBAC.

Amon.
-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.