syslog-ng creates /dev/log in wrong selinux domain causing avc denials

[Stephen Smalley]

On 03/19/2013 11:05 AM, Daniel Neuberger wrote:
> All,
>
> We are getting AVC denials like the following:
>
> audit.log:type=AVC msg=audit(1363623746.304:77): avc:  denied  { write
> } for  pid=7569 comm="audispd" name="log" dev=tmpfs ino=12139
> scontext=system_u:system_r:audisp_t:s0
> tcontext=system_u:object_r:device_t:s0 tclass=sock_file
> audit.log:type=AVC msg=audit(1363628993.829:922): avc:  denied  {
> write } for  pid=8402 comm="logger" name="log" dev=tmpfs ino=12139
> scontext=user_u:system_r:dhcpc_t:s0
> tcontext=system_u:object_r:device_t:s0 tclass=sock_file
> audit.log:type=AVC msg=audit(1363628997.219:952): avc:  denied  {
> write } for  pid=8808 comm="dhclient" name="log" dev=tmpfs ino=12139
> scontext=user_u:system_r:dhcpc_t:s0
> tcontext=system_u:object_r:device_t:s0 tclass=sock_file
> audit.log:type=AVC msg=audit(1363628997.285:955): avc:  denied  {
> write } for  pid=8808 comm="dhclient" name="log" dev=tmpfs ino=12139
> scontext=user_u:system_r:dhcpc_t:s0
> tcontext=system_u:object_r:device_t:s0 tclass=sock_file
> ...
> audit.log:type=AVC msg=audit(1363629158.017:1081): avc:  denied  {
> write } for  pid=9213 comm="logger" name="log" dev=tmpfs ino=12139
> scontext=user_u:system_r:dhcpc_t:s0
> tcontext=system_u:object_r:device_t:s0 tclass=sock_file
> audit.log:type=AVC msg=audit(1363629420.696:1144): avc:  denied  {
> write } for  pid=4944 comm="ntpd" name="log" dev=tmpfs ino=12139
> scontext=system_u:system_r:ntpd_t:s0
> tcontext=system_u:object_r:device_t:s0 tclass=sock_file
> audit.log:type=AVC msg=audit(1363629420.807:1145): avc:  denied  {
> write } for  pid=9700 comm="ntpd" name="log" dev=tmpfs ino=12139
> scontext=user_u:system_r:ntpd_t:s0
> tcontext=system_u:object_r:device_t:s0 tclass=sock_file
> audit.log:type=AVC msg=audit(1363634382.869:2143): avc:  denied  {
> write } for  pid=9973 comm="groupadd" name="log" dev=tmpfs ino=32837
> scontext=user_u:system_r:groupadd_t:s0
> tcontext=user_u:object_r:device_t:s0 tclass=sock_file
> ...
>
> The problem seems to be that syslog-ng is creating /dev/log in the wrong domain:
>
> [root at foo ~]$ ls -Z /dev/log
> srw-rw-rw-  root root user_u:object_r:device_t:s0      /dev/log
> [root at foo ~]$ chcon system_u:object_r:devlog_t:s0 /dev/log
> [root at foo ~]$ ls -Z /dev/log
> srw-rw-rw-  root root system_u:object_r:devlog_t:s0    /dev/log
> [root at foo ~]$ run_init /etc/init.d/syslog-ng restart
> Authenticating foobar.
> Password:
> Restarting syslog-ng: Stopping syslog-ng:                  [  OK  ]
> Starting syslog-ng:                                        [  OK  ]
> [root at foo ~]$ ls -Z /dev/log
> srw-rw-rw-  root root user_u:object_r:device_t:s0      /dev/log
>
> I think this is because the syslog-ng daemon is running in the wrong
> domain.  It never transitions from the initrc_t domain:
>
> [root at foo log]$ ps -efZ | grep syslog
> system_u:system_r:initrc_t:s0   root      4912     1  0 16:20 ?
> 00:00:00 supervising syslog-ng
> system_u:system_r:initrc_t:s0   root      4913  4912  0 16:20 ?
> 00:00:00 /opt/syslog-ng/sbin/syslog-ng --no-caps
>
> The problem - I think - is that we're using a syslog-ng rpm from the
> vendor's website that installs to /opt rather than /usr as the
> targeted policy seems to expect meaning the daemon and everything has
> the wrong file contexts.  I tried fixing this by updating the contexts
> based off the settings in the logging.fc file from the policy src.rpm,
> but that didn't help:
>
> [root at foo ~]$ chcon system_u:object_r:syslog_conf_t:s0 /opt/syslog-ng/etc/*
> [root at foo ~]$ chcon system_u:object_r:syslogd_exec_t:s0 /opt/syslog-ng/sbin/*
> [root at foo ~]$ chcon system_u:object_r:syslogd_var_lib_t:s0
> /opt/syslog-ng/var/syslog-ng.persist
> [root at foo ~]$ chcon system_u:object_r:syslogd_var_lib_t:s0
> /opt/syslog-ng/var/run/*
> [root at foo ~]$ run_init /etc/init.d/syslog-ng restart
> Authenticating foobar.
> Password:
> Restarting syslog-ng: Stopping syslog-ng:                  [  OK  ]
> Starting syslog-ng:                                        [  OK  ]
> [root at foo ~]$ ls -Z /dev/log
> srw-rw-rw-  root root user_u:object_r:device_t:s0      /dev/log
> [root at foo ~]$ ps -efZ | grep syslog
> user_u:system_r:initrc_t:s0     root      6594     1  0 14:35 ?
> 00:00:00 supervising syslog-ng
> user_u:system_r:initrc_t:s0     root      6595  6594  0 14:35 ?
> 00:00:00 /opt/syslog-ng/sbin/syslog-ng --no-caps
>
> Restarting after making these changes, didn't help either.  At this
> point, I'm out of ideas for how to properly fix the problem.  I also
> tried relabeling the whole system, then applying the above changes and
> that didn't help.
>
> FYI, we are running a RHEL 5.5 system, but are using the RHEL 5.7
> kernel and selinux rpms including:
>
> libselinux-1.33.4-5.7.el5.i386
> libselinux-1.33.4-5.7.el5.x86_64
> libselinux-python-1.33.4-5.7.el5.x86_64
> libselinux-utils-1.33.4-5.7.el5.x86_64
> selinux-policy-2.4.6-316.el5.noarch
> selinux-policy-targeted-2.4.6-316.el5.noarch
>
> We're using syslog-ng-3.1.4-1.rhel5.x86_64.rpm from the vendor's
> website which installs everything in /opt/syslog-ng rather than the
> normal RHEL locations.
>
> Any pointers would be much appreciated.  I'm assuming I should be able
> to fix this without modifying the policy, but maybe I'm missing
> something.

Is /opt mounted with nosuid flags?  If so, that will suppress the domain 
transition even if the executable is labeled correctly.

Did you confirm that /opt/syslog-ng/sbin/syslog-ng has the right 
security context with an ls -Z after running the chcon command?  Also, 
if you want this to persist across relabels, you will need to use 
semanage fcontext -a to add definitions to the file_contexts 
configuration for these files so that subsequent relabels will not reset 
them each time.