On 07. nov. 2013 04:06, Steven Haigh wrote: > > While this is interesting, it doesn't provide any methods for auditing > selinux rules. Hi Steven, This can be quite hard. But I'll try to help you understand this topic a little bit better. Unfortunately, it's not easy (for me) to make it quick and short. You need to have some understading of the different contexts SELinux consists of. You have the subject context (the user/process trying to do something) and then you have the target context (the file/object the process wants to access). You can see your current SELinux context using id -Z. On an installation with the 'targetted' policy, you're usually seeing something like this: $ id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ^^^^^^^^^^^^ I won't dwelve too much into details on each field here, but using the targetted policy the highlighed field above is the most important one. You can also run 'ps -Z' to see the SELinux context of all processes. An unconfined_t is basically unrestricted. The idea behind the targetted policy is to only restrict what there exists an explicit policy for. This removes a lot of headache, as you are not forced into preparing policies for everything you run. But if you look carefully at the 'ps -Z' output, you'll see many services being labelled differently. And each of these non unconfied_t processes have explicit policies enabled. You can also look at file contexts, by using 'ls -lZ' So, lets take an example. The Apache httpd process is quite restricted, and may only access files labelled with httpd_sys_content_t, httpd_sys_rw_content_t and http_user_content_t, to mention a few labels [1]. The http_user_content_t is also only available if the httpd_enable_homedirs boolean have been enabled. [1] To see all files httpd is allowed to acces and the needed file contexts, you can run this: semanage fcontext -l | grep httpd_ In addition the process label httpd_t has certain limitations to what it is allowed to run. The policy defines that f.ex. httpd_t cannot run /bin/sh or other shells. So if you try to use the 'newrole' (packaged in policycoreutils-newrole) to switch to a httpd_t context, you'll see this: # newrole -r system_r -t httpd_t /bin/sh failed to exec shell : Permission denied (Disclaimer: this isn't really an appropriate way to do it 100% correct, but it illustrates the restriction) If you look carefully at the file context of /usr/sbin/httpd (ls -lZ), you'll see that it is not labelled httpd_t but httpd_exec_t. This label can do a little bit more, like setting up networking certain ports [2], access certain configuration files and in the end transition the running security context to httpd_t. And this makes it harder for other processes to imitate httpd. [2] To see which ports it is allowed to set up, run: semanage port -l | grep http So ... to your question: How can you check if SELinux is running as it should? It is quite hard to verify it completely, as you need a test program which checks all the different contexts for all the processes you find interesting. This program needs to start with the same context as the policy expects (httpd must start in httpd_exec_t, f.ex). Then it must transition into the running context and try to access files it should be able to access and files it should not be able to touch. Denials is logged in /var/log/audit/audit.log. Further, if your processes uses network sockets, there are additional tests to add here too; but it depends on if the SELinux policy restricts networking or not. In fact, such a test would need to know about all the restrictions the SELinux policy dictates to be able to fully audit if the policy is working. I hope this could help you understand somewhat the complexity of SELinux policy testing. It's not impossible, but it's far from testing file access using chmod and su :) However, a quick'n'diry way of checking if SELinux _seems_ to work for Apache/httpd, is to run: # chcon -vt etc_t /var/www/html If you now try to browse web pages on that server, it should not work. (Please be sure you are running in Enforced SELinux mode). If you then do: # restorecon -Rv /var/www the website should become available again. I've not tested this on my own boxes, but I just expect it to stop working with the wrong file context. However, this doesn't really test the policy thoroughly at all. It will just confirm one of the rules in the policy (The policy is called apache.te in the selinux-policy source rpm) Unfortunately, I'm not aware of any utilities which can be used to test the policies in an easy way. Maybe the SELinux project [3] have something, but I haven't dug into that yet. [3] <http://selinuxproject.org/page/Main_Page> Even though this may look like a really super-quick SELinux crash course, it doesn't really scratch too deep at all. But you shouldn't really need to worry too much about that! Enable SELinux in enforced mode and start from there. It's really not that hard in the end. And unless you have some really non-standard setup, you most likely won't notice much of SELinux at all - except when it should stop something from happening. -- kind regards, David Sommerseth