[rsbac] To-Do List for 1.2.3

[Peter Busser]

Hi!

> * Have it possible to set JAIL for executables in the menus the same way RC
>   types are assigned. It'd be nicer if all RSBAC related things were done
>   through menus, instead of having to hack rsbac_jail commands into startup
>   scripts of things. Hacking the startup scripts is a sure way to cause
>   nasty surprises when one updates the distribution and half a year later
>   realizes the JAILs haven't been in effect ever since the upgrade.

If you hackup the Adamantix init scripts and send in a diff for inclusion in
the distribution, then you won't be surprised next time you update your
Adamantix setup.

> * Paths versus inodes. There are situations where having things based on
>   purely inodes just doesn't cut it. One of them is encountered when I try
>   to limit permissions of fetchmail as much as possible. Fetchmail creates a
>   file ~/.fetchmail.pid and other than that, only alters the mailbox. 
>   Because ~/.fetchmail.pid gets a different inode every time, I can't use
>   RSBAC to allow fetchmail to create only that file, I must allow fetchmail
>   to create any file in ~. Another case is ~/.Xauthority that gets different
>   inode every time.

You could let fetchmail create a pid file in a directory and then let it
inherit the RC type from that directory.

I think it is a bad idea in general to add more complexity to the kernel code
in order to facilitate relatively small problems in applications. The two
(IMHO) biggest threats to MAC frameworks like RSBAC are:

	1) Badly defined policies and
	2) kernel bugs.

Defining a correct policy is easier when the complexity is low, because humans
do not handle complexity well. Adding more complexity is therefore not a good
idea.

A recent bug in the OpenBSD kernel allowed root to circumvent the securlevel
protection. Linux has recently been plagued by several kernel problems as well.
And adding more complexity is one way to make these kind of problems occur
more often.

>   In fact, I'm not sure why RSBAC isn't entirely path based instead of inode
>   based.

For performance reasons obviously.

> Lastly, despite all the problems mentioned above, I think RSBAC is by far
> the best security addition to Linux I've come across, and I believe I've
> seen vast majority of them. Wonderful work, Amon.

I second that. :-)

Groetjes,
Peter Busser
-- 
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/