How SELinux detects bugs

Usually we read the stories about how SELinux prevents malicious activity. This article highlights the use of SELinux even if it is not enforcing. Thus not so much preventing malicious activity but detecting malicious activity.

I am using Fedora9. Since it is still in the first stage and very much a construction site, i had to set SELinux to permissive. This was because X "Spawned to fast¨ and so i could not load a graphical desktop session with SELinux enforced.

Some time later i received an update to the audit package, and after updating my firefox browser wouldnt start any more and so i decided to restart the system. after rebooting my computer, i was no longer able to load a graphical desktop session with SELinux in permissive!

/var/log/messages showed a lot of debug entries for GDM. which only told me that GDM wasnt able to load. So i went to runlevel3 since runlevel 5 did no longer work.

When i logged on as a normal user on TTY1, i was confronted with permission denied messages for /dev/null. After inspecting that location i noticed strange permissions set (400) and so i set it to 777 and rebooted.

After reboot i experienced exactly the same thing. Thats when i knew that something during the startup process messed it up.

So knowing it happend in the startup process i turned to dmesg.

And there it was: SELinux was auditing that it would have denied auditd access to set attributes on /dev/null if it was enforcing.

But it was not enforcing! And so it allowed the auditd domain the set 0400 to /dev/null. Fortunatly SELinux will still log would be denials, even in permissive.

If this was the only reason why my graphical desktop wouldnt load , than it should work with SELinux enforced. Since SELinux would not allow audit to mess with (setattr) /dev/null

And so just before i went to sleep i decided to just try and reboot with SELinux enabled..

..It worked! ...and in the mean time the "X server spawns to fast" issue with SELinux enforcing was also solved.

So thats how SELinux not only protects a system from bugs, but it is also a valuable tool for detection!

Exploring SECMARK

Some servers only accept labeled packets. This can be accomplished by setting the selinux allow_unlabeled_packets boolean off. If you want to connect to such a server than you will have to use properly labeled packets or else the packets will be denied. To label traffic on for example port 22:tcp for OpenSSH you should add a rule to the input and output chain in the mangle table of iptables:

/sbin/iptables -t mangle -A OUTPUT -o eth0 -p tcp --sport 22 -j SECMARK --selctx system_u:object_r:ssh_server_packet_t:s0

/sbin/iptables -t mangle -A INPUT -i eth0 -p tcp --dport 22 -j SECMARK --selctx system_u:object_r:ssh_server_packet_t:s0


This will shape the OpenSSH traffic and add the context needed to get packets accepted on the host:

type=AVC msg=audit(1197570945.629:636): avc: granted { send } for pid=1275 comm="sshd" saddr=10.0.0.101 src=22 daddr=10.0.0.100 dest=39769 netif=eth0 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ssh_server_packet_t:s0 tclass=packet

type=AVC msg=audit(1197572881.868:821): avc: granted { recv } for saddr=10.0.0.100 src=35697 daddr=10.0.0.101 dest=22 netif=eth0 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ssh_server_packet_t:s0 tclass=packet

It will not hurt to label your traffic this way for common daemons as correctly labeled traffic will always be accepted.

unlabeled packets will only be accepted if boolean allow_unlabeled_packets is set to on. This is the default setting.

Auditadm Role

The administrator should assume the appropriate role when performing a task. If the administrator wants to define what is being audited than he should assume the auditadm_r and execute auditctl. This will avoid unnecessary errors.

/etc/audit/audit.rules
The audit documentation directory can be found at:
/usr/share/doc/audit-*