[rsbac] RC Problem with klog and syslogd

[1-IT-4-HOSP]

Hi,

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.
> 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
>   
done.
> 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?
> 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?
>
> 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!

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

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!

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?

Do you have any other ideas what I'm doing wrong?

Dustin