[rsbac] Protecting secoff from malicious root

[Arkady A Drovosekov]

On Fri, Mar 01, 2002 at 11:10:10AM +0000, Rafal Wojtczuk wrote:
> 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.
create user+role for changing passwords only. create wrapper with
additional check uid=400. use only this wrapper to change passwords

> 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
> 	$ 
has login suid bit? how it will work?.. (don't remember such situation)
did you run this fragment under rsbac kernel? you have to add capability to
change uid for desired program

> 	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.
program can not change uid to secoff unless you permit this

> 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.
create role - something like DiskAdmin, assign this role for only [u]mount,fsck
put all disks under this role

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

-- 
Best regards,
Arkady