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@foo ~]$ ls -Z /dev/log
srw-rw-rw- root root user_u:object_r:device_t:s0 /dev/log
[root@foo ~]$ chcon system_u:object_r:devlog_t:s0 /dev/log
[root@foo ~]$ ls -Z /dev/log
srw-rw-rw- root root system_u:object_r:devlog_t:s0 /dev/log
[root@foo ~]$ run_init /etc/init.d/syslog-ng restart
Authenticating foobar.
Password:
Restarting syslog-ng: Stopping syslog-ng: [ OK ]
Starting syslog-ng: [ OK ]
[root@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@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@foo ~]$ chcon system_u:object_r:syslog_conf_t:s0 /opt/syslog-ng/etc/*
[root@foo ~]$ chcon system_u:object_r:syslogd_exec_t:s0 /opt/syslog-ng/sbin/*
[root@foo ~]$ chcon system_u:object_r:syslogd_var_lib_t:s0
/opt/syslog-ng/var/syslog-ng.persist
[root@foo ~]$ chcon system_u:object_r:syslogd_var_lib_t:s0
/opt/syslog-ng/var/run/*
[root@foo ~]$ run_init /etc/init.d/syslog-ng restart
Authenticating foobar.
Password:
Restarting syslog-ng: Stopping syslog-ng: [ OK ]
Starting syslog-ng: [ OK ]
[root@foo ~]$ ls -Z /dev/log
srw-rw-rw- root root user_u:object_r:device_t:s0 /dev/log
[root@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.
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
