rsbac-1.2.3-pre2 on kernel 2.6.0 on SuSE 9.0

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:

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 the
original. No problem inserting it manually.

2) compiling the kernel: do_mounts complained about an undeclared
real_root_dev, quick and dirty solution: turn initrd support OFF in kernel config

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

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

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.

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 run
some services on the machine, so I'm desperate for RSBAC protection. Even if

Re: rsbac-1.2.3-pre2 on kernel 2.6.0 on SuSE 9.0

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 
the
> 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 
config

Another initrd bug is still not fixed: In some cases, you cannot umount the 
initrd.

> 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 
to
> <kerneldir>/include/rsbac/syscalls.h
> 
> after first boot, check syslog for NOT_GRANTED messages and dish out

Re: rsbac-1.2.3-pre2 on kernel 2.6.0 on SuSE 9.0

Amon Ott <ao <at> rsbac.org> irta:
> 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.
I hope that doesn't mean that the main development will be focused to
2.6 only. I think it has to be more tested and needs some time to be as
stable as 2.4.x. Or does it mean that new features/etc will be tested
mostly on 2.6 and you will vmware your 2.4 system on your devel box?
bye,
Ago

-----------
Deim Ágoston
LSC Linux Support Center Kft.
e-mail: deim.agoston <at> lsc.hu
Tel/fax:06-1/341-0457

Re: rsbac-1.2.3-pre2 on kernel 2.6.0 on SuSE 9.0

On Freitag, 2. Januar 2004 12:48, Deim Agoston wrote:
> Amon Ott <ao <at> rsbac.org> irta:
> > 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.
> I hope that doesn't mean that the main development will be focused to
> 2.6 only. I think it has to be more tested and needs some time to be as
> stable as 2.4.x. Or does it mean that new features/etc will be tested
> mostly on 2.6 and you will vmware your 2.4 system on your devel box?
> bye,

As long as 2.6.0 is not rock solid (maybe around 2.6.13, as with 2.2 and 
2.4?), 2.4 will remain the most important line and will run on most of my 
servers. This means that 2.4 will be well supported as long as it is needed 
(just think of 2.2 support still being there in 1.2.2, after two years of 
2.4).

New features are currently developed and first tested on 2.4.23, then they get 
ported to 2.6.0 and tested there. This will change to 2.6 first in the near 
future. Since most of the code is shared for all kernel versions, this is not 
likely to cause any problems.

Instead, the code quality for 2.6 is expected to rise, because I simply test 
it a lot more. OTOH, the 2.4 parts are rock solid, so there is not much to go 
wrong, and it is still running on really many test systems.

Amon.
--

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

Re: rsbac-1.2.3-pre2 on kernel 2.6.0 on SuSE 9.0

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

Re: rsbac-1.2.3-pre2 on kernel 2.6.0 on SuSE 9.0

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!

New serious kernel vulnerability

Hi!

Unfortunately, a new serious kernel vulnerability has been discovered in the 
2.4 series. The attached patch fixes the code in the sys_mremap system call, 
it is included in the just released 2.4.24 kernel.

Exploit code has been claimed to be existing, but has not yet been published.

I am currently testing the RSBAC 1.2.2 port to 2.4.24, so please stay tuned if 
you plan to update your kernel ASAP.

Amon.
--

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

_______________________________________________
rsbac mailing list
rsbac <at> rsbac.org
http://www.rsbac.org/mailman/listinfo/rsbac

Linux: 2.4.24 Stable Kernel Released

Hello,

Summary of changes from v2.4.23 to v2.4.24-rc1
============================================

<marcelo.tosatti:[blocked]>:
  o Andrea Arcangeli: malicious users of mremap() syscall can gain
  priviledges

Just a quick question - is RSBAC vulnerable to that case?

Thanks,

michal

patch-2.4.24-rsbac-v1.2.2 uploaded to /pre

Hi!

The RSBAC v1.2.2 patch for kernel 2.4.24 has been uploaded to
http://rsbac.org/pre

The prepatched kernel source archive is still uploading to the same dir.

Amon.
--

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

Re: Linux: 2.4.24 Stable Kernel Released

On Montag, 5. Januar 2004 16:39, Michal Medvecky wrote:
> Summary of changes from v2.4.23 to v2.4.24-rc1
> ============================================
> 
> <marcelo.tosatti:[blocked]>:
>   o Andrea Arcangeli: malicious users of mremap() syscall can gain
>   priviledges
> 
> 
> Just a quick question - is RSBAC vulnerable to that case?

Yes, same problem as with do_brk. However, so far there does not seem to be 
any exploit code floating around, only claims. See http://lists.netsys.com/
pipermail/full-disclosure/2004-January/015198.html

The 2.4.24 patch for RSBAC 1.2.2 is out in /pre, so you can update. 
Alternatively, use the patch for earlier kernels I posted.

Amon.
--

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