[rsbac] kernel oops accessing /dev/log

[Vincent Danen]

Hi everyone.  I've got a bit of a problem with rsbac 1.2.5.1 and kernel
2.4.32.  When I try to "ls /dev/log" or run initlog (which a number of
initscripts do), I'm getting a segfault of the application and a kernel
oops printed to the screen:


 <1>Unable to handle kernel NULL pointer dereference at virtual address
00000001
 printing eip:
c0146885
*pde = 2f042067
*pte = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0146885>]    Not tainted
EFLAGS: 00010202
eax: 00000001   ebx: 0000000f   ecx: ef0c845c   edx: ef1c0f60
esi: 00000000   edi: bffffa0c   ebp: ece63fbc   esp: ece63f40
ds: 0018   es: 0018   ss: 0018
Process initlog (pid: 827, stackpage=ece63000)
Stack: f0bc2d99 ef1d7238 00000002 ef4cf800 ef1d7238 c0146b49 08051380
00000000 
       ef195860 ece63f98 f0bbf987 ef1d7258 ef195840 08051380 00000292
ef190901 
       0000009e ef6ec2c0 ef195860 ef195840 ef1c0f60 effe9360 ef6ec2c0
ef195840 
Call Trace:    [<f0bc2d99>] [<c0146b49>] [<f0bbf987>] [<c0108bf3>]

Code: 83 38 01 0f 84 47 ff ff ff 8d 81 20 01 00 00 bb 0b 00 00 00 


Now, syslog still seems to work properly.  Ie. these errors are being
properly logged to syslog.  And if I do "logger mark" I get the
appropriate:

Feb  8 15:15:57 cerberus vdanen: mark

in syslog.  So I'm not sure if rsbac is protecting /dev/log in some way
that's preventing initlog from playing nice with it.  The strange thing
is only one machine is exhibiting this behaviour (with or without
rsbac_softmode).  I tested this same kernel (well, compiled with same
options and patches) in vmware (one x86, another x86_64), and on an
athlon (the one that fails) and an opteron, but the others work ok.  The
rest of the system seems fine.

I have the kernel compiled with:

[root at cerberus etc]#  cat /proc/rsbac-info/active 
Version: 1.2.5
Mode: SOFTMODE
Softmode: available
Ind-Soft: available
Switching: available for
Module: REG  on
Module: DAZ  on
Module: FF   on
Module: CAP  on
Module: JAIL on
Module: RES  on

(i just booted into softmode to see if I got the same behaviour).  The
previous kernel did not do this (only change are the rsbac additions).
The kernel is 2.4.32 with minimal patches; the only one that conflicted
in any way with rsbac was the openwall kernel patch, but the rejected
changesets were quite minimal and really shouldn't interfere, at least
not for this.

Has anyone come across anything like this before?

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
Wasting time like it was free...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://www.rsbac.org/pipermail/rsbac/attachments/20060208/2d641e74/attachment.bin