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.
Thanks.
- Daniel
On Tue, 2013-03-19 at 11:05 -0400, Daniel Neuberger wrote:
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
Domain type transitions happen on execve. So you need to make sure that both the init script as well as the syslog executable file are labeled properly.
its like this:
init_t -> initrc_exec_t -> initrc_t -> syslog_exec_t -> syslogd_t
You seem to be hanging at initrc_t so i suspect that your syslog executable file is mislabeled.
Verify the syslogd init script file and see what it runs when it starts syslog, then see if that file has a proper label.
Thanks.
- Daniel
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On Tue, Mar 19, 2013 at 11:50 AM, Dominick Grift dominick.grift@gmail.com wrote:
Domain type transitions happen on execve. So you need to make sure that both the init script as well as the syslog executable file are labeled properly.
its like this:
init_t -> initrc_exec_t -> initrc_t -> syslog_exec_t -> syslogd_t
You seem to be hanging at initrc_t so i suspect that your syslog executable file is mislabeled.
Verify the syslogd init script file and see what it runs when it starts syslog, then see if that file has a proper label.
Thanks Dominick. The file run by the syslogd init script has the proper label, but I realized that the init script itself was labeled initrc_t instead of sylogd_script_exec_t, but fixing that still didn't help:
[root@foo ~]$ chcon system_u:object_r:syslogd_script_exec_t:s0 /etc/init.d/syslog-ng [root@foo ~]$ ls -Z /etc/init.d/syslog-ng /opt/syslog-ng/sbin/syslog-ng -rwxr-xr-x root root system_u:object_r:syslogd_script_exec_t:s0 /etc/init.d/syslog-ng -rwxr-xr-x root root system_u:object_r:syslogd_exec_t:s0 /opt/syslog-ng/sbin/syslog-ng [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 ~]$ ps -efZ | grep syslog user_u:system_r:initrc_t:s0 root 7199 1 0 16:30 ? 00:00:00 supervising syslog-ng user_u:system_r:initrc_t:s0 root 7200 7199 0 16:30 ? 00:00:00 /opt/syslog-ng/sbin/syslog-ng --no-caps
I agree with your diagnosis, but fixing the labeling doesn't seem to help. Any other ideas?
Thanks.
- Daniel
On Tue, 2013-03-19 at 12:40 -0400, Daniel Neuberger wrote:
On Tue, Mar 19, 2013 at 11:50 AM, Dominick Grift dominick.grift@gmail.com wrote:
Domain type transitions happen on execve. So you need to make sure that both the init script as well as the syslog executable file are labeled properly.
its like this:
init_t -> initrc_exec_t -> initrc_t -> syslog_exec_t -> syslogd_t
You seem to be hanging at initrc_t so i suspect that your syslog executable file is mislabeled.
Verify the syslogd init script file and see what it runs when it starts syslog, then see if that file has a proper label.
Thanks Dominick. The file run by the syslogd init script has the proper label, but I realized that the init script itself was labeled initrc_t instead of sylogd_script_exec_t, but fixing that still didn't help:
[root@foo ~]$ chcon system_u:object_r:syslogd_script_exec_t:s0 /etc/init.d/syslog-ng [root@foo ~]$ ls -Z /etc/init.d/syslog-ng /opt/syslog-ng/sbin/syslog-ng -rwxr-xr-x root root system_u:object_r:syslogd_script_exec_t:s0 /etc/init.d/syslog-ng -rwxr-xr-x root root system_u:object_r:syslogd_exec_t:s0 /opt/syslog-ng/sbin/syslog-ng [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 ~]$ ps -efZ | grep syslog user_u:system_r:initrc_t:s0 root 7199 1 0 16:30 ? 00:00:00 supervising syslog-ng user_u:system_r:initrc_t:s0 root 7200 7199 0 16:30 ? 00:00:00 /opt/syslog-ng/sbin/syslog-ng --no-caps
I agree with your diagnosis, but fixing the labeling doesn't seem to help. Any other ideas?
Stephen has a good suggestion. See if your /opt is mounted with nosuid. If it is then it cannot domain type transition.
Thanks.
- Daniel
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.
On 03/19/2013 12:41 PM, Stephen Smalley wrote:
Is /opt mounted with nosuid flags? If so, that will suppress the domain transition even if the executable is labeled correctly.
That's it!!! Well mostly... Removing nosuid from /opt and rebooting worked except that syslog-ng isn't starting at all now due to the following denials: ------------- type=AVC msg=audit(1363713616.722:556): avc: denied { execute_no_trans } for pid=5857 comm="syslog-ng" path="/opt/syslog-ng/libexec/syslog-ng" dev=dm-6 ino=190556 scontext=user_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:syslogd_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1363713616.722:556): arch=c000003e syscall=59 success=no exit=-13 a0=400740 a1=7fffe72f8908 a2=1a2e5010 a3=0 items=1 ppid=5849 pid=5857 auid=515 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=2 comm="syslog-ng" exe="/opt/syslog-ng/sbin/syslog-ng" subj=user_u:system_r:syslogd_t:s0 key=(null)
type=CWD msg=audit(1363713616.722:556): cwd="/"
type=PATH msg=audit(1363713616.722:556): item=0 name="/opt/syslog-ng/libexec/syslog-ng" inode=190556 dev=fd:06 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:syslogd_exec_t:s0 ------------- In plain English from sealert, 'SELinux is preventing syslog-ng (syslogd_t) "execute_no_trans" to /opt/syslog-ng/libexec/syslog-ng (syslogd_exec_t).'
Is system_u:object_r:syslogd_exec_t:s0 the wrong label for /opt/syslog-ng/libexec/syslog-ng? I tried this instead to no avail:
[root@sdi-u-unstable audit]$ chcon system_u:object_r:syslogd_t:s0 /opt/syslog-ng/libexec/syslog-ng chcon: failed to change context of /opt/syslog-ng/libexec/syslog-ng to system_u:object_r:syslogd_t:s0: Permission denied
At this point, I'm unsure if it's a labeling problem or if I need to add a new rule due to the addition of /opt/syslog-ng/libexec/syslog-ng in the newer versions of syslog-ng.
Thanks for all the help.
- Daniel
On 03/19/2013 01:42 PM, Daniel Neuberger wrote:
On 03/19/2013 12:41 PM, Stephen Smalley wrote:
Is /opt mounted with nosuid flags? If so, that will suppress the domain transition even if the executable is labeled correctly.
That's it!!! Well mostly... Removing nosuid from /opt and rebooting worked except that syslog-ng isn't starting at all now due to the following denials:
type=AVC msg=audit(1363713616.722:556): avc: denied { execute_no_trans } for pid=5857 comm="syslog-ng" path="/opt/syslog-ng/libexec/syslog-ng" dev=dm-6 ino=190556 scontext=user_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:syslogd_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1363713616.722:556): arch=c000003e syscall=59 success=no exit=-13 a0=400740 a1=7fffe72f8908 a2=1a2e5010 a3=0 items=1 ppid=5849 pid=5857 auid=515 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=2 comm="syslog-ng" exe="/opt/syslog-ng/sbin/syslog-ng" subj=user_u:system_r:syslogd_t:s0 key=(null)
type=CWD msg=audit(1363713616.722:556): cwd="/"
type=PATH msg=audit(1363713616.722:556): item=0 name="/opt/syslog-ng/libexec/syslog-ng" inode=190556 dev=fd:06 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:syslogd_exec_t:s0
In plain English from sealert, 'SELinux is preventing syslog-ng (syslogd_t) "execute_no_trans" to /opt/syslog-ng/libexec/syslog-ng (syslogd_exec_t).'
Is system_u:object_r:syslogd_exec_t:s0 the wrong label for /opt/syslog-ng/libexec/syslog-ng? I tried this instead to no avail:
[root@sdi-u-unstable audit]$ chcon system_u:object_r:syslogd_t:s0 /opt/syslog-ng/libexec/syslog-ng chcon: failed to change context of /opt/syslog-ng/libexec/syslog-ng to system_u:object_r:syslogd_t:s0: Permission denied
At this point, I'm unsure if it's a labeling problem or if I need to add a new rule due to the addition of /opt/syslog-ng/libexec/syslog-ng in the newer versions of syslog-ng.
Normally you would only label the entrypoint executable for syslogd (i.e. the executable invoked to launch syslogd) with syslogd_exec_t, not helper programs internally called by it. Anything else would get labeled with a different type, which could just be bin_t for libexec files. But you may also need to add an allow rule via local policy module to allow this if it is new behavior for syslog-ng.
On 03/19/2013 01:57 PM, Stephen Smalley wrote:
On 03/19/2013 01:42 PM, Daniel Neuberger wrote:
On 03/19/2013 12:41 PM, Stephen Smalley wrote:
Is /opt mounted with nosuid flags? If so, that will suppress the domain transition even if the executable is labeled correctly.
That's it!!! Well mostly... Removing nosuid from /opt and rebooting worked except that syslog-ng isn't starting at all now due to the following denials:
type=AVC msg=audit(1363713616.722:556): avc: denied { execute_no_trans } for pid=5857 comm="syslog-ng" path="/opt/syslog-ng/libexec/syslog-ng" dev=dm-6 ino=190556 scontext=user_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:syslogd_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1363713616.722:556): arch=c000003e syscall=59 success=no exit=-13 a0=400740 a1=7fffe72f8908 a2=1a2e5010 a3=0 items=1 ppid=5849 pid=5857 auid=515 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=2 comm="syslog-ng" exe="/opt/syslog-ng/sbin/syslog-ng" subj=user_u:system_r:syslogd_t:s0 key=(null)
type=CWD msg=audit(1363713616.722:556): cwd="/"
type=PATH msg=audit(1363713616.722:556): item=0 name="/opt/syslog-ng/libexec/syslog-ng" inode=190556 dev=fd:06 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:syslogd_exec_t:s0
In plain English from sealert, 'SELinux is preventing syslog-ng (syslogd_t) "execute_no_trans" to /opt/syslog-ng/libexec/syslog-ng (syslogd_exec_t).'
Is system_u:object_r:syslogd_exec_t:s0 the wrong label for /opt/syslog-ng/libexec/syslog-ng? I tried this instead to no avail:
[root@sdi-u-unstable audit]$ chcon system_u:object_r:syslogd_t:s0 /opt/syslog-ng/libexec/syslog-ng chcon: failed to change context of /opt/syslog-ng/libexec/syslog-ng to system_u:object_r:syslogd_t:s0: Permission denied
At this point, I'm unsure if it's a labeling problem or if I need to add a new rule due to the addition of /opt/syslog-ng/libexec/syslog-ng in the newer versions of syslog-ng.
Normally you would only label the entrypoint executable for syslogd (i.e. the executable invoked to launch syslogd) with syslogd_exec_t, not helper programs internally called by it. Anything else would get labeled with a different type, which could just be bin_t for libexec files. But you may also need to add an allow rule via local policy module to allow this if it is new behavior for syslog-ng.
Also, what you tried to do (in labeling the libexec file with syslogd_t) isn't desirable because it conflates a domain type (syslogd_t) used for processes with a file type (e.g. syslogd_exec_t, bin_t, ...). The only case where a domain type should appear on a "file" is for the /proc/pid entries associated with a process in that domain. It shouldn't be used on regular files.
On 03/19/2013 02:00 PM, Stephen Smalley wrote:
Normally you would only label the entrypoint executable for syslogd (i.e. the executable invoked to launch syslogd) with syslogd_exec_t, not helper programs internally called by it. Anything else would get labeled with a different type, which could just be bin_t for libexec files. But you may also need to add an allow rule via local policy module to allow this if it is new behavior for syslog-ng.
Also, what you tried to do (in labeling the libexec file with syslogd_t) isn't desirable because it conflates a domain type (syslogd_t) used for processes with a file type (e.g. syslogd_exec_t, bin_t, ...). The only case where a domain type should appear on a "file" is for the /proc/pid entries associated with a process in that domain. It shouldn't be used on regular files.
Thanks! Using your advice, I was able to get it working by adding the below to the policy: ---------------------------- require { type syslogd_t; type var_t; type bin_t; class process getsched; class file { read execute execute_no_trans }; class dir write; }
#============= syslogd_t ============== allow syslogd_t bin_t:file { read execute execute_no_trans }; allow syslogd_t self:process getsched; allow syslogd_t var_t:dir write; ---------------------------- Any recommendations on whether that seems like the right solution? I'm new to writing policy, but it seems too permissive to me. Anyone have a reference that would help me to recognize the difference between a good policy and something that just allows whatever to make it work?
Also, why does nosuid suppress domain transitions? I couldn't find any details on Google or in the RHEL docs.
Thanks again for all the help.
On 03/19/2013 03:39 PM, Daniel Neuberger wrote:
On 03/19/2013 02:00 PM, Stephen Smalley wrote:
Normally you would only label the entrypoint executable for syslogd (i.e. the executable invoked to launch syslogd) with syslogd_exec_t, not helper programs internally called by it. Anything else would get labeled with a different type, which could just be bin_t for libexec files. But you may also need to add an allow rule via local policy module to allow this if it is new behavior for syslog-ng.
Also, what you tried to do (in labeling the libexec file with syslogd_t) isn't desirable because it conflates a domain type (syslogd_t) used for processes with a file type (e.g. syslogd_exec_t, bin_t, ...). The only case where a domain type should appear on a "file" is for the /proc/pid entries associated with a process in that domain. It shouldn't be used on regular files.
Thanks! Using your advice, I was able to get it working by adding the below to the policy:
require { type syslogd_t; type var_t; type bin_t; class process getsched; class file { read execute execute_no_trans }; class dir write; }
#============= syslogd_t ============== allow syslogd_t bin_t:file { read execute execute_no_trans }; allow syslogd_t self:process getsched; allow syslogd_t var_t:dir write;
Any recommendations on whether that seems like the right solution? I'm new to writing policy, but it seems too permissive to me. Anyone have a reference that would help me to recognize the difference between a good policy and something that just allows whatever to make it work?
Also, why does nosuid suppress domain transitions? I couldn't find any details on Google or in the RHEL docs.
Thanks again for all the help.
Not sure why you need the getsched rule; that should already be allowed.
The var_t rule seems too broad; I suspect you should have a more specific type on the directory in question (would have to see the audit messages).
We followed the existing convention that nosuid disables security state changes for executables in that filesystem and applied it to SELinux security contexts in addition to the existing restrictions on setuid/setgid executables. If you didn't trust setuid/setgid bits from that filesystem, why would you trust security contexts from it? But in retrospect, it might have been better to have a separate flag for that purpose.
On 03/19/2013 04:01 PM, Stephen Smalley wrote:
We followed the existing convention that nosuid disables security state changes for executables in that filesystem and applied it to SELinux security contexts in addition to the existing restrictions on setuid/setgid executables. If you didn't trust setuid/setgid bits from that filesystem, why would you trust security contexts from it? But in retrospect, it might have been better to have a separate flag for that purpose.
Interesting. I guess I can see both sides. In our case, we have a separate requirement to specify nosuid, but now we have to justify not doing so in order to keep SELinux working. So it makes sense to me from a technical standpoint, but decisions aren't always made that way. So I agree that having a separate flag would be useful to allow more flexibility. Thanks for the explanation.
One more question. I tried putting my semanage calls to update the file contexts in a custom rpm depending on the selinux-policy-targeted rpm. In the rpm scriptlet, I first made all the semanage calls and then called restorecon on the appropriate paths so that the new file contexts would be applied without having to relabel the entire file system. This all works except when the rpm is installed by anaconda during a kickstart install. In that case, I have to run restorecon again during kspost or manually after the install. Any ideas why or suggestions for a better solution?
For those interested, here is a summary of the complete solution to get the syslog-ng daemon as installed by the balabit rpms on RHEL 5 working with selinux:
* Make sure nosuid is not set on /opt * Update file contexts: /usr/sbin/semanage fcontext -a -t syslogd_script_exec_t /etc/init.d/syslog-ng /usr/sbin/semanage fcontext -a -t syslogd_exec_t /opt/syslog-ng/sbin/syslog-ng /usr/sbin/semanage fcontext -a -t var_run_t /opt/syslog-ng/var/run /usr/sbin/semanage fcontext -a -t syslogd_var_lib_t /opt/syslog-ng/var/syslog-ng.persist /usr/sbin/semanage fcontext -a -t syslogd_var_lib_t /opt/syslog-ng/var/run/syslog-ng.pid /usr/sbin/semanage fcontext -a -t syslogd_var_lib_t /opt/syslog-ng/var/run/syslog-ng.ctl /usr/sbin/semanage fcontext -a -t syslog_conf_t /opt/syslog-ng/etc/syslog-ng.conf * Apply changes to file contexts: restorecon -R /opt/syslog-ng/ /etc/init.d/syslog-ng
* save local.te: -------------------------------- module sdi_syslog 1.0;
require { type syslogd_t; type var_t; type bin_t; class process getsched; class file { read execute execute_no_trans }; class dir write; }
#============= syslogd_t ============== allow syslogd_t bin_t:file { read execute execute_no_trans }; allow syslogd_t self:process getsched; allow syslogd_t var_t:dir write; --------------------------------
* Compile and install our local syslog-ng selinux policy: checkmodule -M -m -o local.mod local.te semodule_package -o local.pp -m local.mod semodule -i local.pp
* If you had to update the mount options on /opt, reboot * Otherwise, run: rm -f /dev/log service syslog-ng restart * Verify that syslog is running in syslogd_t type domain and that /dev/log is created as type devlog_t
...
FYI, the local policy is probably too permissive as Stephen mentioned in one of the previous posts. Hopefully, I will find time to fix that eventually at which point I will try to remember to post an update. Until then though, this is the best I've got.
Suggestions are welcomed.
Thanks so much for the help!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/21/2013 03:54 PM, Daniel Neuberger wrote:
On 03/19/2013 04:01 PM, Stephen Smalley wrote:
We followed the existing convention that nosuid disables security state changes for executables in that filesystem and applied it to SELinux security contexts in addition to the existing restrictions on setuid/setgid executables. If you didn't trust setuid/setgid bits from that filesystem, why would you trust security contexts from it? But in retrospect, it might have been better to have a separate flag for that purpose.
Interesting. I guess I can see both sides. In our case, we have a separate requirement to specify nosuid, but now we have to justify not doing so in order to keep SELinux working. So it makes sense to me from a technical standpoint, but decisions aren't always made that way. So I agree that having a separate flag would be useful to allow more flexibility. Thanks for the explanation.
One more question. I tried putting my semanage calls to update the file contexts in a custom rpm depending on the selinux-policy-targeted rpm. In the rpm scriptlet, I first made all the semanage calls and then called restorecon on the appropriate paths so that the new file contexts would be applied without having to relabel the entire file system. This all works except when the rpm is installed by anaconda during a kickstart install. In that case, I have to run restorecon again during kspost or manually after the install. Any ideas why or suggestions for a better solution?
For those interested, here is a summary of the complete solution to get the syslog-ng daemon as installed by the balabit rpms on RHEL 5 working with selinux:
- Make sure nosuid is not set on /opt * Update file contexts:
/usr/sbin/semanage fcontext -a -t syslogd_script_exec_t /etc/init.d/syslog-ng /usr/sbin/semanage fcontext -a -t syslogd_exec_t /opt/syslog-ng/sbin/syslog-ng /usr/sbin/semanage fcontext -a -t var_run_t /opt/syslog-ng/var/run /usr/sbin/semanage fcontext -a -t syslogd_var_lib_t /opt/syslog-ng/var/syslog-ng.persist /usr/sbin/semanage fcontext -a -t syslogd_var_lib_t /opt/syslog-ng/var/run/syslog-ng.pid /usr/sbin/semanage fcontext -a -t syslogd_var_lib_t /opt/syslog-ng/var/run/syslog-ng.ctl /usr/sbin/semanage fcontext -a -t syslog_conf_t /opt/syslog-ng/etc/syslog-ng.conf
You pobably want to run all these commands within a transaction.
Something like
semanage -i << _EOF fcontext -a -t syslogd_script_exec_t /etc/init.d/syslog-ng fcontext -a -t syslogd_exec_t /opt/syslog-ng/sbin/syslog-ng ... _eof
Should make it run a lot faster.
- Apply changes to file contexts: restorecon -R /opt/syslog-ng/
/etc/init.d/syslog-ng
I have no idea why this would fail unless the restorecon is failing for some reason. I guest I would put selinux-policy-base in a Requires(Post) block to make sure it is installed.
- save local.te: -------------------------------- module sdi_syslog 1.0;
require { type syslogd_t; type var_t; type bin_t; class process getsched; class file { read execute execute_no_trans }; class dir write; }
#============= syslogd_t ============== allow syslogd_t bin_t:file { read execute execute_no_trans }; allow syslogd_t self:process getsched; allow syslogd_t var_t:dir write; --------------------------------
- Compile and install our local syslog-ng selinux policy: checkmodule -M -m
-o local.mod local.te semodule_package -o local.pp -m local.mod semodule -i local.pp
- If you had to update the mount options on /opt, reboot * Otherwise, run:
rm -f /dev/log service syslog-ng restart * Verify that syslog is running in syslogd_t type domain and that /dev/log is created as type devlog_t
..
FYI, the local policy is probably too permissive as Stephen mentioned in one of the previous posts. Hopefully, I will find time to fix that eventually at which point I will try to remember to post an update. Until then though, this is the best I've got.
Suggestions are welcomed.
Thanks so much for the help!
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Daniel Neuberger -
Dominick Grift -
Stephen Smalley