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