RE: RSBAC suggestions / Problems

From: Amon Ott <ao@rsbac.org>
Subject: RE: RSBAC suggestions / Problems
Date: Wed, 11 Jul 2001 10:26:16 +0200

Next Article (by Subject): RE: RSBAC suggestions / Problems Amon Ott
Previous Article (by Subject): RE: RSBAC suggestions / Problems "Kaladis"
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:
> > 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.

So you could still use the daemon version, if necessary. I have a useradd
wrapper here, which automatically sets RSBAC RC roles and types as needed for
every new user.

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

Another solution would be per-user mounts, which will probably come in 2.5
kernel series, or redirection.

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

There are basically two different ways of processes interacting:

1. Tracing and signals (the target process does not know what will happen)
2.  Inter Process Communication - two or more processes agree on a communication
channel

Both ways can be controlled with RSBAC, e.g. with RC model:

1. Set the def_process_create_type of the role running the process to another
process type and control access to that type.

2. Set the def_ipc_create_type of the role to another ipc type and control
access to that type.

With ACL, you can only change the process or ipc default ACL, e.g. remove TRACE
right.

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

You and all others: Do you think, there should be a global RSBAC config switch
'Disable Linux filesystem access control', which disables all Linux filesystem
access control in vfs_permission()?

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

On Usenix conference, I heard people complain about any difference. Specially
many main kernel developers think that any general performance loss by
possibly more security is not acceptable. For me, like you, performance is less
important than security.

However, I never measured the difference, because I would have to change all
the code. As RSBAC checks are only avoided, if Linux disallows access, it
cannot be that much.

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.