[rsbac] RC Problem with klog and syslogd

Amon Ott ao at rsbac.org
Sat Oct 27 18:47:56 CEST 2007


On Friday 26 October 2007 15:08, 1-IT-4-HOSP wrote:
> I've activated softmode to configure RSBAC. Since the first boot
> I've the problem that the klod and syslogd interrupt each other so
> I get tons of messages (about 250 per second) like these:
>
> Oct 25 18:07:33 lenny kernel: 0000200341|rsbac_adf_request():
> request SEND, pid 1985, ppid 1, prog_name klogd, prog_file
> /sbin/klogd, uid 0, target_type UNIXSOCK, tid Device 00:14 Inode
> 6049 Path /log, attr process, value 1975, result NOT_GRANTED
> (Softmode) by RC
>
> Oct 25 18:07:33 lenny kernel: 0000200342|rsbac_adf_request():
> request RECEIVE, pid 1975, ppid 1, prog_name syslogd, prog_file
> /sbin/syslogd, uid 0, target_type UNIXSOCK, tid Device 00:14 Inode
> 6049 Path /log, attr process, value 1975, result NOT_GRANTED
> (Softmode) by RC

So klogd (pid 1985) sends data to syslogd (pid 1975) through Unix 
socket /dev. Two things that look wrong:

- Path should usually be /dev/log (is /log correct in your system?)
- The RECEIVE request should show the other process 1985 as partner 
process (value of attribute "process"). This may be caused by 
sys_sendto, where the receiver does not see the sender's pid.

> So I "killall klogd" to work on the  system and try to allow the
> klogd. I used
> http://www.rsbac.org/wiki/experiences/telmich#configuring_bind9_dns
>_server as example, because there was a "RC-Problem" too.
>
> -> rsbac_rc_role_menu -> new role (with new id and name) -> Type
> Menu -> and now I see the problem. My target_type is UNIXSOCK and I
> can't choose anything like that. Nevertheless I tried it with the
> FD-Type (and continue everything like the "documentation" told me)
> but it didn't work (wasn't a surprise for me ;)).

UNIXSOCK is one of the filesystem (FD) targets, so Type Comp FD is 
correct.

> Does anyone know how I can fix this problem?

First of all, you should enable RC debugging to see the exact role and 
type involved. Either use rsbac_debug_adf_rc kernel parameter, or as 
user 400 (secoff) call:

echo debug_adf_rc 1 >/proc/rsbac-info/debug

Depending on your setup, klogd's and syslogd's role are either 999999 
(boot role) or 2 (root's role). The RC type of /log is 0 by default.

Let us assume the role is 2. Then as user 400 call
rsbac_rc_role_menu 2
and select Type Comp FD, select type 0, and allow requests CONNECT, 
SEND and RECEIVE. This should silence the log messages and allow your 
system to work. If it does not, you hit a bug.


Now for some first idea of using roles and types:

If the previous steps work fine, you can use
- rsbac_rc_type_menu to define a new FD type "Log socket"
- rsbac_rc_role_menu to copy role 2 to a new role "Logging Daemon" 
- "rsbac_fd_menu /usr/sbin/syslogd" to assign the new role as 
Force Role to syslogd
- rsbac_rc_role_menu to give the Logging Daemon role CREATE LISTEN 
ACCEPT RECEIVE GET_STATUS_DATA on the "Log socket" type and set Log 
socket as Def Unixsock Create Type of the role
- use "rsbac_rc_role_menu 2" to allow root processes to reach /log: 
Type Comp FD, "Log socket", CONNECT SEND GET_STATUS_DATA
- Restart syslogd (to get the new role) and klogd (to reconnect to the 
new syslogd)

You might need more rights, but the RC debugging will quickly show 
which. Also, some daemons probably run with Boot Role 999999, so as 
quick solution use "rsbac_rc_role_menu 999999" to give this role 
logging rights, too.

When this works (and you have no other named Unix sockets used in the 
system, otherwise you might have to care for them, too), you can 
remove CONNECT SEND RECEIVE rights to RC Type FD 0 from all roles to 
make sure that
1. Only syslogd can open a logging socket
2. All programs can only connect to syslogd's Unix socket

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


More information about the rsbac mailing list