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

Amon Ott ao at rsbac.org
Fri Jan 2 11:23:06 CET 2004

Hi Fabian!

On Donnerstag, 1. Januar 2004 16:52, Fabian Kiendl wrote:
> A Happy New Year 2004! As part of my resolution not to procrastinate on
> security matters, here's a brief report on my experiment of installing
> rsbac-1.2.3-pre2 on top of kernel 2.6.0 on top of SuSE 9.0:

Thanks for your report!
> 1) patching the kernel: 1 reject in mm/mmap.c, which was not inserted
> automatically because the code lines after the RSBAC insert had changed in 
> original. No problem inserting it manually.

There will be a pre3 for 2.6.0 pretty soon, with some bug fixes and better 
AUTH learning.
> 2) compiling the kernel: do_mounts complained about an undeclared
> real_root_dev, quick and dirty solution: turn initrd support OFF in kernel 

Another initrd bug is still not fixed: In some cases, you cannot umount the 
> 3) compilation of admin tools: like in an earlier post on this list, there
> was an undefined reference to errno so "#include <errno.h>" had to be added 
> <kerneldir>/include/rsbac/syscalls.h
> after first boot, check syslog for NOT_GRANTED messages and dish out
> permissions accordingly. There were a lot less adjustments to make than with
> previous RSBAC versions, notably there were no kmem GET_STATUS_DATA 
complaints from
> system services because there is an ACL entry for USER_0 (root) by default.

Will be rechecked.
> What I still keep getting since RSBAC installation is "bad: scheduling while
> atomic!" kernel traces, but without any obvious discomfort so far.

Yes, still on my to-do list for pre3. It is a locking issue in the rsbacd 
thread, so it should not interfere with normal processes.
> What puzzles me is that I can do "echo abcdefgh > /dev/kmem" as root which
> causes an oops and ends my root shell without RSBAC intervening.

OK, will check it.
> Surprisingly positive experience so far, given that I'm using a development
> version of RSBAC that isn't even meant to be installed on top of my kernel.
> But I need kernel 2.6.0 for some pieces of hardware to work and I need to 
> some services on the machine, so I'm desperate for RSBAC protection. Even if
> the machine should freeze, I'd prefer that to being 0wn3d.

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.

In general, please note that main development is currently still on 2.4.23. 
2.6.0 will be supported, but less well checked. One reason is that my vmware 
test system does not yet run smoothly with 2.6, e.g. loadkeys crashes, and 
that the current Debian stable does not work well with 2.6. I expect to move 
over to 2.6 before 1.2.3-final, though.

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

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

More information about the rsbac mailing list