Good times for developers & administrators with SELinux in Fedora Core 5

I’ve just read Dan Walsh‘s latest in a long series or articles on SELinux and am very excited to hear about both the new modular SELinux policy and the introduction of the semanage tool.

Good times for administrators

Since the initial debut of SELinux in Fedora Core 2, great progress has been made in ensuring that all applications distributed in core operate correctly when SELinux is enabled. The bug-bear for administrators, however, has been the situations where they have to make customizations not anticipated by the engineers writing the policy. The the simple example of changing Apache to also listen on port 8001, as well as the usual port 80, has always been much harder than it ought to be. It would typically require downloading the policy module sources, finding the place to add in the extra port definition, re-building the binary policy module and finally loading it into the kernel. With soo much work required for a simple change of port number, it is not so surprising that SELinux can cause much frustration for administrators. This has unfortuntately reflected negatively on SELinux as a whole – I say unfortunately, because at the end of the day this is really just a tools problem – not a technology problem. With the arrival of Fedora Core 5, I am very happy to see that the new semanage tool has dramatically changed this situation for the better.

Going back to my example of changing Apache to run on port 8001. If we edit httpd.conf at this time to change ‘Listen 80’ to ‘Listen 8001’ & restart apache, we ought to see it fail to start because port 8001 is not a normal Apache port:

# sed -e 's/Listen 80/Listen 8001/' /etc/httpd/conf/httpd.conf
#  /etc/init.d/httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd:                                            [FAILED]
# tail /var/log/audit/audit.log
type=AVC msg=audit(1142888562.766:5739): avc:  denied  { name_bind } for  pid=12524 comm="httpd" src=8001 scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1142888562.766:5739): arch=c000003e syscall=49 success=no exit=-13 a0=5 a1=5555556ac660 a2=10 a3=7ffffff0c8fc items=0 pid=12524 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd" exe="/usr/sbin/httpd"
type=SOCKADDR msg=audit(1142888562.766:5739): saddr=02001F41000000000000000000000000

The manpage says that the ‘-l’ argument to semanage will list the configuration for the different types of managed object – files, ports, users, etc. So to see what ports the current policy allows for apache lets try looking for anything related to ‘http’ (if you don’t know what type to look for double-check /var/log/audit/audit.log):

# semanage port -l | grep http
http_cache_port_t              tcp      3128, 8080, 8118
http_cache_port_t              udp      3130
http_port_t                    tcp      80, 443, 488, 8008, 9050

A quick glance at this output shows that the http_port_t type is the one of interest to us. The ‘add’ command to semanage allows this list of ports to be extended, so lets add port 8001 & verify that it has updated the policy

# semanage port -a -t http_port_t -p tcp 8001
# semanage port -l | grep http
http_cache_port_t              tcp      3128, 8080, 8118
http_cache_port_t              udp      3130
http_port_t                    tcp      8001, 80, 443, 488, 8008, 9050

So, now try starting apache again:

# /etc/init.d/httpd start
Starting httpd:                                            [  OK  ]

So no more need to interpret, edit & re-compile obscure policy files, just run single command and Apache is all set to listen on port 8001. Good times indeed!

Good times for developers

With the introduction of modular policy it is also finally possible for application developers to start bundling SELinux policy files within with their main release tar.gz downloads. By making it feasible for upstream developers to start including their application’s policy in the primary release tar.gz bundles, there is much greater incentive for developers to both learn & maintain the policy themselves, removing the policy maintainence bottleneck. In addition, it will make it possible for applications not included in Fedora Core itself – eg the thousands of apps in Fedora Extras – to start supplying policies in their own RPMs. Obviously these apps will need to take care to ensure their add-on policy doesn’t compromise the wider system policy, but the design of the modular policy ought to help prevent such problems.

These two (at first) simple sounding enhancements, should be the catalyst for SELinux to reach an even wider community of developers & remove much of the burden previously felt by adminstrators. Kudos to all the SELinux developers who worked on this step forward. I’m now off to write policy for Test-AutoBuild :-)