RE: RSBAC suggestions / Problems

From: "Kaladis" <kaladis@gmx.de>
Subject: RE: RSBAC suggestions / Problems
Date: Tue, 10 Jul 2001 19:40:55 +0200

Next Article (by Subject): RE: RSBAC suggestions / Problems "Kaladis"
Previous Article (by Subject): Re: RSBAC suggestions / Problems Amon Ott
Top of Thread: RSBAC suggestions / Problems "Kaladis"
Next in Thread: RE: RSBAC suggestions / Problems "Kaladis"
Articles sorted by: [Date] [Author] [Subject]

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.

public_html would be wwwoff.httpd rwx--x--- then - no problem with that
username would have to be username.wwwoff then rwxrwxr-x - no problem with
that

All files that the user uploads would be username.username rw-r----- then
but they would have to be username.wwwoff rw-rw-r--

umask could maybe be forced via ACL :DEFAULT: settings. ugroup? There's
nothing like it...

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

True, true.

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

Deactivated all REG modules that could change RSBAC behavious on the fly.
Was too risky IMHO.

> 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.

Using the Openwall patch is a cure anyways. Temp path is set to +t so no
hardlinks can be created. That solves the /tmp race condition
vulnerabilities

> 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?

I'm not that experienced with the way how processes in *nix work. My thought
was that if multiple processes run as daemon then these processes could talk
to each other or could interact with other running processes. So to speak I
was thinking about isolating them not only via a chrooted() jail but also on
the process level.

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

That's very true indeed, but it's easy to achieve that easily with ACL's
anyways. I see ACL's as an extension of the normal rights - so once you're
used to it you can completely forget about the UNIX rights. Isn't that
complicated... and from that point of view I would say that it'd be ok

> 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.

How significant is this difference? For my distro I'm already spending about
10% of performance at cost of security (setting stack, heap, data and bss to
non-exec), I'm prepared to spend another 10. Doesn't make that much of a
difference on i686 anyways.

- Jörg Lübbert

-
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.