[rsbac] Protecting secoff from malicious root

[Amon Ott]

On Sunday, 3. March 2002 19:47, Rafal Wojtczuk wrote:
> On Fri, Mar 01, 2002 at 06:06:25PM +0100, Amon Ott wrote:
> > 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.
>
> I would like to allow ordinary users to change their own passwords, too :)

Certainly - you could e.g. allow shadow write access to anyone except root.

Alternatively, you can use a passwd wrapper, which checks uid and params 
before passing on to real passwd. If only this wrapper gets the 'Password 
Change' role, it should be fine.

> > BTW, you can easily prevent execution of other programs through RC role
> > process_execute_type value no_execute.
>
> OK, but we must remember thet if an attacker can force a privileged process
> to run a machine code injected by the attacker (note I avoided the word
> "shellcode"), the attacker doesn't need to execute anything to take full
> advantage of the process' privileges.

Right. All we can do here is strip down the process rights as much as 
possible without preventing the intended functionality.

What we can get is that after a reboot the system works as intended. Program 
malfunctioning (e.g. though bugs or attacks) cannot be principally prevented.

> > > 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.
>
> One must also avoid race conditions: an attacker can inject keystrokes
> after the tty has been allocated, but before the login script runs.

We could have another role attribute 'tty_dev_type', which gets assigned to 
the terminal when the role gets assigned to the process. Would that be 
sufficient?

> > > 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.
>
> "all partitions": what do you mean ? All entries in /dev ? What If I do
> # mknod myhda b 3 0
> # debugfs -w ./myhda
> Or should all mknod operations be disallowed (which is tricky to enforce; I
> can write to /dev/hdaX a filesystem containing device pseudofiles and then
> mount /dev/hdaX).

/dev/[sh]d* and what else might be used as partitions, e.g. fd*, md*. 
Certainly no char devices.

Types are assigned to the devices, not to the special files. mknod would not 
change anything.

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