From mboxrd@z Thu Jan  1 00:00:00 1970
From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Thu, 04 Nov 2010 09:09:05 -0400
Subject: [refpolicy] How unix_dgram_socket object's sensitivity level
 is	determined?
In-Reply-To: <SNT139-w4683CE3C95D7B5ABE9500EAB4B0@phx.gbl>
References: <SNT139-w4683CE3C95D7B5ABE9500EAB4B0@phx.gbl>
Message-ID: <4CD2B071.4080205@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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