[refpolicy] How unix_dgram_socket object's sensitivity level is determined?

[refpolicy] How unix_dgram_socket object's sensitivity level is determined?

[HarryCiao]

Hi SELinux experts,

When I am playing with the latest refpolicy git tree with the MLS feature enabled, I run into a huge chunk of error messages of:

type=1400 audit(1288773294.060:386): avc:  denied  { sendto } for  pid=459 comm="klogd" path="/dev/log" scontext=system_u:system_r:klogd_t:s0-s15:c0.c1023 tcontext=system_u:system_r:syslogd_t:s15:c0.c1023 tclass=unix_dgram_socket

We are clear that the klogd_t domain have the needed permissions both to write the /dev/log socket file and send to the unix domain socket bond with it: 

root at qemu-host:/root> newrole -r secadm_r -- -c "sesearch -SCA -s klogd_t -t devlog_t -c sock_file"
Password: 
Found 1 semantic av rules:
   allow klogd_t devlog_t : sock_file { write getattr append open } ; 

root at qemu-host:/root> newrole -r secadm_r -- -c "sesearch -SCA -s klogd_t -t syslogd_t -c unix_dgram_socket"

Password: 

Found 1 semantic av rules:

   allow klogd_t syslogd_t : unix_dgram_socket sendto ; 

So clearly it is the MLS constraint related with the sendto permission of the unix_dgram_socket class blocked the above operation.

My first question is how an object of the unix_dgram_socket class has its sensitivity level determined?

Another thing, I found the sensitivity level of the /dev/log is not correct:

root at qemu-host:/root> ls -Z /dev/log
srw-rw-rw-  root root system_u:object_r:devlog_t:s15:c0.c1023 /dev/log
root at qemu-host:/root> restorecon /dev/log
root at qemu-host:/root> ls -Z /dev/log
srw-rw-rw-  root root system_u:object_r:devlog_t:s0    /dev/log
root at qemu-host:/root> 

Although I could fix it by restorecon as above, but after reboot, its sensitivity level is still not correct:

root at qemu-host:/root> ls -Z /dev/log
srw-rw-rw-  root root system_u:object_r:devlog_t:s15:c0.c1023 /dev/log
root at qemu-host:/root> 

So my second question is who may have changed the sensitivity level of /dev/log during system booting up?

Last, as for the MLS constraint related with the sendto permission of the unix_dgram_socket class,  the ms_trusted_object() interface will add the calling domain to the mlstrustedobject attribute, well the mls_socket_write_all_levels() interface will add the calling domain to the mlsnetwrite attribute:

kernel/terminal.te:mls_trusted_object(devtty_t)
kernel/terminal.te:mls_trusted_object(ptmx_t)
kernel/selinux.te:mls_trusted_object(security_t)
kernel/devices.te:mls_trusted_object(null_device_t)
kernel/devices.te:mls_trusted_object(zero_device_t)
services/cups.te:mls_trusted_object(cupsd_var_run_t)
system/init.te:mls_trusted_object(initctl_t)
system/setrans.te:mls_trusted_object(setrans_var_run_t)
system/logging.te:mls_trusted_object(devlog_t)

services/cups.te:mls_socket_write_all_levels(cupsd_t)
services/dbus.te:mls_socket_write_all_levels(system_dbusd_t)
system/setrans.te:mls_socket_write_all_levels(setrans_t)
- system/logging.te:mls_socket_write_all_levels(syslogd_t)           # removed from the latest git tree

How do we decide for which domain should have these interfaces called? For example, would it make sense at all to call mls_trusted_object() on syslogd_t? Why not? How should I know?

Thank you very much!

Best regards,
Harry
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20101104/8658d928/attachment.html 

[refpolicy] How unix_dgram_socket object's sensitivity level is determined?

[Christopher J. PeBenito]

On 11/03/10 23:25, HarryCiao wrote:
> Hi SELinux experts,
> 
> When I am playing with the latest refpolicy git tree with the MLS
> feature enabled, I run into a huge chunk of error messages of:
> 
> type=1400 audit(1288773294.060:386): avc:  denied  { sendto } for 
> pid=459 comm="klogd" path="/dev/log"
> scontext=system_u:system_r:klogd_t:s0-s15:c0.c1023
> tcontext=system_u:system_r:syslogd_t:s15:c0.c1023 tclass=unix_dgram_socket
> 
> We are clear that the klogd_t domain have the needed permissions both to
> write the /dev/log socket file and send to the unix domain socket bond
> with it:
> 
> root at qemu-host:/root> newrole -r secadm_r -- -c "sesearch -SCA -s
> klogd_t -t devlog_t -c sock_file"
> Password:
> Found 1 semantic av rules:
>    allow klogd_t devlog_t : sock_file { write getattr append open } ;
> 
> root at qemu-host:/root> newrole -r secadm_r -- -c "sesearch -SCA -s
> klogd_t -t syslogd_t -c unix_dgram_socket"
> Password:
> Found 1 semantic av rules:
>    allow klogd_t syslogd_t : unix_dgram_socket sendto ;
> 
> So clearly it is the MLS constraint related with the sendto permission
> of the unix_dgram_socket class blocked the above operation.
> 
> My first question is how an object of the unix_dgram_socket class has
> its sensitivity level determined?
> 
> Another thing, I found the sensitivity level of the /dev/log is not correct:
> 
> root at qemu-host:/root> ls -Z /dev/log
> srw-rw-rw-  root root system_u:object_r:devlog_t:s15:c0.c1023 /dev/log
> root at qemu-host:/root> restorecon /dev/log
> root at qemu-host:/root> ls -Z /dev/log
> srw-rw-rw-  root root system_u:object_r:devlog_t:s0    /dev/log
> root at qemu-host:/root>
> 
> Although I could fix it by restorecon as above, but after reboot, its
> sensitivity level is still not correct:
> 
> root at qemu-host:/root> ls -Z /dev/log
> srw-rw-rw-  root root system_u:object_r:devlog_t:s15:c0.c1023 /dev/log
> root at qemu-h ost:/root>
> 
> So my second question is who may have changed the sensitivity level of
> /dev/log during system booting up?

Actually, the original context was technically correct.  /dev/log is
recreated by syslogd every time it starts, and the default level of a
file is the level of the creating process.  I will fix the file contexts
in refpolicy.

> Last, as for the MLS constraint related with the sendto permission of
> the unix_dgram_socket class,  the ms_trusted_object() interface will add
> the calling domain to the mlstrustedobject attribute, well the
> mls_socket_write_all_levels() interface will add the calling domain to
> the mlsnetwrite attribute:
> 
> kernel/terminal.te:mls_trusted_object(devtty_t)
> kernel/terminal.te:mls_trusted_object(ptmx_t)
> kernel/selinux.te:mls_trusted_object(security_t)
> kernel/devices.te:mls_trusted_object(null_device_t)
> kernel/devices.te:mls_trusted_object(zero_device_t)
> services/cups.te:mls_trusted_object(cupsd_var_run_t)
> system/init.te:mls_trusted_object(initctl_t)
> system/setrans.te:mls_trusted_object(setrans_var_run_t)
> system/logging.te:mls_trusted_object(devlog_t)
> 
> services/cups.te:mls_socket_write_all_levels(cupsd_t)
> se rvices/dbus.te:mls_socket_write_all_levels(system_dbusd_t)
> system/setrans.te:mls_socket_write_all_levels(setrans_t)
> - system/logging.te:mls_socket_write_all_levels(syslogd_t)           #
> removed from the latest git tree
> 
> How do we decide for which domain should have these interfaces called?
> For example, would it make sense at all to call mls_trusted_object() on
> syslogd_t? Why not? How should I know?

In this case we don't want to mls_socket_write_all_levels() on all the
domains that log to syslog, since we only need this exception when
talking to syslogd.  So the right thing to do would be to add
mls_trusted_object() to syslogd_t.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com