[rsbac] RC Problem with klog and syslogd

[Amon Ott]

On Tuesday 30 October 2007 16:52, 1-IT-4-HOSP wrote:
> Amon Ott schrieb Am 27.10.2007 18:47:
> > 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.
>
> "/log" is _not_ correct in my system. It's the default directory
> "/dev/log" and I don't see the reason why the messages says "/log".
> I tried to start "syslogd" with the parameter "-p /dev/log" to
> force "syslogd" to use "/dev/log", no changes.
> Then I tried "strace -f syslogd", but it says that it uses
> "/dev/log" (than it's unlinked by the -p parameter and again set to
> "/dev/log"), so that looks right for me.

This means that the RSBAC inheritance code does not work correctly. 
What filesystem type is /dev? What exact kernel sources do you use?

> > 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.
>
> Which "setup" do you mean? The "make menuconfig" before compiling?

Your role configuration, and whether there is a setuid(0) somewhere in 
the init chain, which changes the role from 999999 to 2.

> > 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.
>
> I tried 2 and 999999 neither of them worked. Is it correct that
> CONNECT, SEND, RECEIVE (and several others) are per default allowed
> for type 0?

They should be.

> > 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)
>
> Even though the previous steps haven't work fine, I tried it with
> your instructions without any success.
> Here the "new" (with debug messages) errors:
>
> Oct 30 16:55:26 rsbac-etch kernel: 0000023806|rsbac_adf_request():
> request SEND, pid 1792, ppid 1, prog_name klogd, prog_file
> /sbin/klogd, uid 0, target_type UNIXSOCK, tid Device 00:14 Inode
> 4838 Path /log, attr process, value 1786, result NOT_GRANTED
> (Softmode) by RC
>
> Oct 30 16:55:26 rsbac-etch kernel: 0000023807|check_comp_rc(): pid
> 1786 (syslogd), owner 0, rc_role 4, PROCESS rc_type 0, request
> RECEIVE -> NOT_GRANTED!

Here we come to the clue: You enabled "Check partner process" in the 
kernel config. You need to allow RECEIVE for role 4 to PROCESS type 0 
(type_comp_process).

> Oct 30 16:55:26 rsbac-etch kernel: 0000023808|rsbac_adf_request():
> request RECEIVE, pid 1786, ppid 1, prog_name syslogd, prog_file
> /sbin/syslogd, uid 0, target_type UNIXSOCK, tid Device 00:14 Inode
> 4838 Path /log, attr process, value 1786, result NOT_GRANTED
> (Softmode) by RC

This is what comes as a result. With the partner process check, there 
are actually two requests in one.

> Oct 30 16:55:26 rsbac-etch kernel: 0000023809|check_comp_rc(): pid
> 1792 (klogd), owner 0, rc_role 999999, PROCESS rc_type 0, request
> SEND -> NOT_GRANTED!

Similar here: role 999999 needs SEND on PROCESS type 0.

> FYI: Maybe you remark that it's an other hostname... I reinstalled
> Debian completely (this time without upgrading to Lenny, so this
> time it's Etch), recompiled the rsbac-kernel and admin-tools, and
> installed everything. I think there shouldn't be a problem that I
> run the distribution in a VBox, right?

VMWare etc. are no problem.

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