headers
kang | 19 Feb 2008 12:01

RSBAC 1.3.7 Released


RSBAC 1.3.7 has been released for both kernels 2.4.36 and 2.6.23.15

You can download the new version from http://www.rsbac.org/download
(Quick download from http://www.rsbac.org/download/quick).

Improvements over the previous version (1.3.6)

  * Supports secure delete on XFS and JFS
  * New kernel parameter rsbac_list_recover to register lists even if
reading from disk fails
  * Correct pam install location automatically on x86_64
  * Many bugs fixed

See http://download.rsbac.org/code/1.3.7/changes-1.3.7.txt for more details.

Thanks and have fun using RSBAC!

Note: the 2.6.23.14 prepatched kernel includes the recent kernel
vulnerability fixes.

Note: the 2.6.24 patch will be posted shortly, when the new PID code
required to support this kernel has been tested long enough.
Permalink | Reply | 0 comments |
headers
E. de Ruiter | 22 Feb 2008 15:25
Picon

2 problems with 1.3.7

Hi,

I just tried out the new enhanced kernel with rsbac 1.3.7 and it seems 
that 2 problems that we had with the previous version (enhanced 2.6.21 
kernel with rsbac 1.3.4) are still present (note: I never reported these 
problems up until now because we didn't have time to report these 
problems ..)

1)
On our test-cluster we boot from network (nfs-root filesystem), but this 
gives a problem with rsbac:
we get tons of "rsbac_get_parent(): oops - d_parent == dentry_p!" on the 
console rendering the system unusable.
For that reason we comment out the rsbac_printk call in rsbac_get_parent 
and then everything works fine (I have no idea was this message means 
and if it could do any harm .. but the system is completely usable after 
this edit).

2)
On our production cluster we saw lots of kernel-oopses in originating 
from the do_sock_read function. After some investigation it was clear 
that most of the time postfix was triggering the oops. We ran some tests 
on our test-cluster with smtp-source/smtp-sink (postfix benchmark tools) 
and it turned out we could trigger the oops reliable when using 1 
smtp-sink instance and 2 smtp-source instances each delivering 200 
messages which are quite large.
We also tested this without hyperthreading enabled on the machines 
(effectively making it a non-smp kernel) without hyperthreading we 
couldn't reproduce the problem. Also on a vanilla kernel this problem 
doesnot occur.
(Continue reading)

Permalink | Reply | 3 comments |
headers
kang | 22 Feb 2008 17:40

Re: 2 problems with 1.3.7

E. de Ruiter wrote:
> Hi,
>
> I just tried out the new enhanced kernel with rsbac 1.3.7 and it seems 
> that 2 problems that we had with the previous version (enhanced 2.6.21 
> kernel with rsbac 1.3.4) are still present (note: I never reported these 
> problems up until now because we didn't have time to report these 
> problems ..)
>
> 1)
> On our test-cluster we boot from network (nfs-root filesystem), but this 
> gives a problem with rsbac:
> we get tons of "rsbac_get_parent(): oops - d_parent == dentry_p!" on the 
> console rendering the system unusable.
> For that reason we comment out the rsbac_printk call in rsbac_get_parent 
> and then everything works fine (I have no idea was this message means 
> and if it could do any harm .. but the system is completely usable after 
> this edit).
>
> 2)
> On our production cluster we saw lots of kernel-oopses in originating 
> from the do_sock_read function. After some investigation it was clear 
> that most of the time postfix was triggering the oops. We ran some tests 
> on our test-cluster with smtp-source/smtp-sink (postfix benchmark tools) 
> and it turned out we could trigger the oops reliable when using 1 
> smtp-sink instance and 2 smtp-source instances each delivering 200 
> messages which are quite large.
> We also tested this without hyperthreading enabled on the machines 
> (effectively making it a non-smp kernel) without hyperthreading we 
> couldn't reproduce the problem. Also on a vanilla kernel this problem
(Continue reading)

Permalink | Reply | 2 comments |
headers
Arnaud Patard | 22 Feb 2008 17:59

Re: 2 problems with 1.3.7

kang <kang <at> rsbac.org> writes:
Hi,

> 1)
> About your issue #1 this is "normal" for some filesystem which do not
> initialize properly, and the inheritance is broken. However this does
> flood the syslog for every access (NFS access here) and we might need to

you can try limiting the flood with printk_ratelimit() if it's not
already done :)

Arnaud
Permalink | Reply | 1 comment |
headers
Amon Ott | 26 Feb 2008 08:48

Re: 2 problems with 1.3.7

On Friday 22 February 2008 17:59, Arnaud Patard wrote:
> kang <kang <at> rsbac.org> writes:
> Hi,
>
> > 1)
> > About your issue #1 this is "normal" for some filesystem which do
> > not initialize properly, and the inheritance is broken. However
> > this does flood the syslog for every access (NFS access here) and
> > we might need to
>
> you can try limiting the flood with printk_ratelimit() if it's not
> already done :)

All RSBAC messages to syslog are rate limited, if you enabled it in 
RSBAC kernel config. The default values might be a bit high, you can 
change them in kernel config, or adjust the real values at boot and 
runtime.

E.g. to set the limit at 20/s:
echo "debug syslog_rate 20" > /proc/rsbac_info/debug

Or use kernel parameter
rsbac_syslog_rate=20

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
Permalink | Reply | 0 comments |

Gmane