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

[Amon Ott]

On Samstag, 3. Januar 2004 10:44, Fabian Kiendl wrote:
> > 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.

Make a backup with auth_back_cap and run the resulting restore script after 
update. If you only check AUTH changes with RC module and assign a sufficient 
RC role to the restore script, you can even do this without softmode.
 
> 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!

OK, I will try to make sure that the related code gets serialized to avoid the 
problem.
 
> > 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

Right, this is a good approach, I am doing this myself.

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

Better this way than a well logged break-in... :)

BTW, you can also use CAP module to remove most (if not all) suid root 
settings for binaries and start some services as a normal user. This is what 
Peter Busser currently does for Adamantix.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22