Re: RSBAC suggestions / Problems

From: Amon Ott <ao@rsbac.org>
Subject: Re: RSBAC suggestions / Problems
Date: Tue, 10 Jul 2001 14:26:33 +0200

Next Article (by Author): Re: RSBAC suggestions / Problems Amon Ott
Previous Article (by Author): rsbac-v1.1.2-pre7 uploaded Amon Ott
Top of Thread: RSBAC suggestions / Problems "Kaladis"
Next in Thread: Re: RSBAC suggestions / Problems Amon Ott
Articles sorted by: [Date] [Author] [Subject]

On Die, 10 Jul 2001 Kaladis wrote:
> Having toyed around with RSBAC I came to the conclusion that one of the most
> efficient modules is the ACL module.
> 
> To improve ACL's further I have got 3 suggestions that are very useful:
> 
> A) Pattern Matching
> B) IPC ACL inheritance from file
> C) ACL > POSIX
> 
> In the following I descrive my points with giving aswell scenarios:
> 
> A)
> 
> Patter matching could also be best described as globbing.
> 
> A scenario would be a multi-homed apache webserver with mod_userdir that
> reads out home/username/public_html.
> In my particular setup I do not want to administrate webpages with root but
> with wwwoff. To achieve this I would have to give wwwoff root equivalent
> rights for certain areas. People with access to /home/username/public_html
> should be wwwoff(rw) username(rw) and httpd(r) - however /home/username
> should not be readable by httpd and not rw by wwwoff. Instead of generating
> ACL's for every user it would be very interesting to have only one ACL with
> pathname of /home/*/public_html minus exceptions

RSBAC in general is completely inode-number-based, so decisions based on the
pathname are possible, but not (yet) supported by any existing module. This
makes it difficult to apply pattern matching rules directly. Pathname based
decision can also lead to various problems, e.g. with mount points and hard
links.

There are at least two solutions:
1. do not use /home/username/public_html, but /public_html/username. To keep
apache happy, you can provide /home/username/public_html as a symlink to
/public_html/username, accessible via SEARCH and GET_STATUS_DATA.

A simple wrapper for useradd can do this setup for you (or the ACL settings...).

Because of ACL inheritance, all httpd rights administration can be done on
/public_html.

2. Have a daemon (or REG module) regularly apply rules to new user dirs

> Having just read about a tripwire /tmp race condition I came to the
> conclusion that it would also be very nifty for a hotfix beeing able to deny
> access to /tmp/twXXXXX (ie. /tmp/tw??????).

Sorry, not likely to be possible soon. Hardcoded /tmp is a terrible mess, there
should be a common environment variable like in good old DOS.

> B)
> 
> I would like to be able to control IPC better so that I can not only select
> a Process from the running Processes but also just a normal binary with
> extra ACL-entries which are then inherited to all resulting processes and
> childs. This could be pretty useful to isolate processes entirely and not
> only filesystem-wise. Isn't that a B1 requirement?

Are you talking about IPC between processes or processes as objects, e.g. for
signals or tracing?

> C)
> 
> It would be also very useful to be able to have ACL's judged higher than the
> normal Unix rights. In my particular setup I have home/username/public_html.
> As mentioned above I want to administrate it with wwwoff and don't want to
> give root the ability to access this. All files in /home/username should be
> of course chowned to username.username. At best only rw to username and r to
> username(group). That's why creating a rule for the httpd user so that he
> can only read files and creating a rule for wwwoff so that he can also
> readwrite files is what would make a very secure HTTPD environment possible.

Disabling or overriding Linux access control is very dangerous, because you
must be absolutely sure to make a proper ACL setup.

The current RSBAC interception design prevents RSBAC functions from being
called, if Linux access control denied access. The main reason is a significant
difference in performance.

Even if we always called RSBAC and made a common decision, the Metapolicy
would have to be changed from 'restrictive' to something else. Only the
restrictive version makes all policies independent from each other.

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.