[rsbac] rsbac-1.2.3-pre2 on kernel 2.6.0 on SuSE 9.0

[Fabian Kiendl]

> There will be a pre3 for 2.6.0 pretty soon, with some bug fixes and better
> 
> AUTH learning.

AUTH learning is no problem. When I install a new program I must check
syslog and update AUTH - it's as simple as that. What is still a bit annoying is
that all AUTH capabilities are bound to the file's inode. When I run SuSE's
automatic update (RSBAC does not free me from keeping my system patched), I
have to check manually which critical binaries are updated, and re-grant them
AUTH capabilities.

> The current state on rsync will fix some of your bugs, so you might
> consider 
> using the new code. I hope to be able to make the promised pre3 next week.

Fixing small bugs is not so much a priority for me, so I'll most probably
wait with a new install and reboot until some more glaring (security?) bugs are
fixed. For now most important thing is that I do not run too high a risk by
opening services to the outside world, because that machine does many things
at once.

I still got the SMP boot problem that was discussed on this list a while ago
(CLOSE request by "boot", target type FIFO,
http://www.rsbac.org/pipermail/rsbac/2003-September/000666.html). Work-around: add the "rsbac_softmode"
parameter in /etc/lilo.conf to boot in softmode, and disable softmode as soon as
possible by inserting "switch_module SOFTMODE 0" at the top of
/etc/rc.d/boot.local. That way I'm sure the machine comes back up after a power failure, and
the switch_module is executed before network is up. The nifty thing is that
this is a one-way switch - root can't change this back!

> Additionally, there might be some interceptions missing on new syscalls
> etc. 
> in 2.6., and the sysfs code still has to be properly controlled.

Even with basic functionality you get a fair level of security, e.g. by
placing each server inside its own JAIL and locking down the files in that JAIL
using RC, FF and ACL, and locking down system binaries as well. Every exploit
attempt is going to generate a lot of syslog output before the attacker
eventually succeeds at circumventing RSBAC. This can be monitored to e.g. initiate
an emergency lockdown using iptables, and the loghost gathers enough
evidence to maybe nail the attacker. I haven't ever gotten any really alarming
messages from RSBAC in the past year I've been using it, however, because keeping
the system patched and opening only necessary services - basic hygiene -
remains first line of defence.

Fabian