[rsbac] Protecting secoff from malicious root

[Rafal Wojtczuk]

Hello,
	One of the goals of rsbac seems to be restricting the root user's 
privileges. Yet, having read available documentation, including the mailing 
list archive, I have not found any extensive guide on how to configure a
common Linux system so that the compromised root could do little harm. Of 
course, the details depend on the server's functionality, yet a few
problems mentioned below are generic and deserve to be explicitely covered.
	Below I enclose a few methods enabling root to take control over
secoff. I find them either untrivial or hard to fix. Probably most can be 
fixed by careful rsbac configuration (I would like to be presented examples), 
but a few are tougher.
 
1) It looks sane to assume that root should be allowed to change other user's
passwords. Therefore, root can change secoff's password and login as secoff.

2) rsbac assigns privileges to binaries. Root can take control over a
process in many ways:
	a) ptracing a privileged binary
	b) using environment variables meaningful for a dynamic linker; for
example, the following code gives to root a shell with secoff's uid:
	# cat ld.c
	_init()
	{
		unsetenv("LD_PRELOAD");
		setuid(400);
		exec("/bin/sh","sh",0);
	}
	# gcc -c ld.c
	# ld -shared -o ld.so ld.o
	# LD_PRELOAD=./ld.so /bin/login
	$ 

	c) finally, giving extra privileges to binaries which were meant to
be run by usual superuser only is a bad idea. Such binaries are very likely
to have numerous security problems (format bugs, buffer overflows etc). Also
think about things like spawning shell form editor (:!/bin/sh in vi). It is
easy to miss such.

3) How about stuffing keystrokes into tty queues ? Root can wait for secoff
to log in, then root can send characters to secoff's terminal with
ioctl(secoffs_terminal_fd, TIOCSTI, ptr_to_char)
and thus invoke arbitrary commands as secoff.

4) /dev/kmem seems to be protected by default, but /dev/hda is not. I could
for instance access files in /rsbac with debugfs utility.

5) How to restrict kernel modules loading so that only during system boot it
would be possible to load one ?

6) It looks sane to assume that root should be allowed to mount filesystems.
If, say, /lib is protected read-only by rsbac, is it possible to mount
a malicious custom filesystem on /lib ?

7) setfsuid() syscall ? Is it protected on 2.2.x kernels ? If root can execute
setfsuid(400), he would be able to alter secoff's .bash_login file etc.
 
What do you think ? Can anyone mention other neccesary things to take care of 
when deploying rsbac ?

Save yourself,
Nergal