[rsbac] Protecting secoff from malicious root

[Amon Ott]

On Friday, 1. March 2002 12:10, Rafal Wojtczuk wrote:
> 	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.

The whole standard /bin/login procedure is insecure in itself, because of the 
password problem.

One way of protection would be to use a different way of login for secoff, 
e.g. via ssh, and disallow changing to secoff uid for /bin/login.

If you really have to use /bin/login and need a superuser being able to 
change everybody's password, you could use secoff or another user for that 
task - just prevent writing to /etc/shadow by anybody else.

> 2) rsbac assigns privileges to binaries. Root can take control over a
> process in many ways:
> 	a) ptracing a privileged binary

You need TRACE right to the process target for that. Just turn it off.

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

If you want to be sure, use a statically linked login program and disallow 
MAP_EXEC for it (new request in 1.2.0). Or only allow EXECUTE/MAP_EXEC on 
predefined executable and library files (also works with 1.1.2). The latter 
is part of my standard setup.

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

Except CAP module, RSBAC only further restricts access rights.

Sure programs can be buggy - if you assign a role to a program, you should be 
careful about the role's privileges. On the other hand, there simply are 
tasks that require extra privileges, and I want to control which programs can 
perform them.

BTW, you can easily prevent execution of other programs through RC role 
process_execute_type value no_execute.

It is better to run a buggy program with some privileges as a normal user 
than running it with all privileges as a superuser.

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

Let the secoff login script assign another RC type to the controlling tty, 
which root has no right to access. I'd have to check, whether the ioctl is 
controlled - if not, this hole should be fixed.

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

Right. The base setup must plain work to get people up and running.

In my usual setup, all partitions get a special RC type, which only role FSCK 
(assigned to /sbin/fsck) can read-write and root can only mount/umount.

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

Have a special initial role on your boot script, which allows module loading, 
disallow for sysadm and set force_role of /bin/login or /bin/bash to 
always_inherit_user.

I usually have a special role module-loader anyway, which is the only one 
allowed to load modules, but can only read-open files of type modules (e.g. 
assigned to /lib/modules). The role is assigned to insmod. This way, no 
uncontrolled modules can be loaded.

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

Root only under certain circumstances, which you can define through assigned 
roles, e.g. only in boot script.

Mounting to a dir is treated as a write access, so FF flag read-only on the 
dir prevents mounting. You can also explicitely prohibit MOUNT right in 
several other models.

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

setfsuid is no longer protected, because it gives no RSBAC privileges.

Certainly, secoff's home dir (e.g. /secoff) should be protected by RC types 
etc., not by Linux DAC. The predefined type Security FD suits well for that.

> What do you think ? Can anyone mention other neccesary things to take care
> of when deploying rsbac ?

Yes, please, go ahead... ;)

Amon.
--
http://www.rsbac.org