Is SELinux hard to understand?
 

Hello all.
Is Selinux hard to understanding?

Thanks.

it depends who's doing the understanding really. It's generally classed as an "advanced" subject, so compared to other areas, yes it's probably fair to say it's complicated.

is it Complex?

I already answered your question. Use of synonyms don't change anything.

If your looking to try to understand it, I think that Gentoo has some pretty good documentation with a good mix of both theory and practice. Link to enough reading material to keep you busy for a while.

Complex ? yes
but Hard ? NO !!
and is VERY EASY VERY EASY to use now

back in 2005 not so much
but now in 2012 - VERY EASY to use

You could try reading the relevant chapters here http://www.linuxtopia.org/online_boo...ion/index.html.
It certainly takes a while to get your head around, unless you are already familiar with the general concepts/theory.

RBAC has been used "forever" in some other universes.
SELinux is not hard to understand when it's working - just look at Fedora; these days most people probably don't even disable it, they don't even know it's there. But it can be a mongrel when it's not (working). Although as @John VV points out above, things is better these days. There are even tools that accept the error message and give you a proposed solution - which is generally pretty close to the mark.

SElinux is easy if you just want to protect services (for example apache).
You only need to give the correct context to the files/dirs and enable some booleans for using php db connects for example.

If you want to create own policies it might be more complex. But that is not the use for most users.

It is not nearly as difficult as it use to be. Get a copy of CENTOS or something like that and google around for some documentation and just play around with it. As another user said working with selinux with the services that it protects out of the box is pretty straightforward. Having to write your own custom policies can be tricky. You can always put selinux in permissive mode, see what get's blocked and figure out a policy rule from that.

The tools to manage selinux have improved significantly over the years.

IMHO, the part about how SELinux works is fairly straightforward. Contexts, booleans and such don't take much to understand.

The more complicated part, and I still haven't found a sufficient explanation for this, has more to do with how/when to create custom policies.

I have several servers that have had SELinux either Disabled or Permissive for a long time and now I'm trying to sift through the audit logs to make sure I don't break everything when I turn it on.

While it's easy enough to use commands like ausearch and audit2allow, the issue is whether or not some of the activity is SUPPOSED to be allowed and if it IS, then why is SELinux trying to block it? I haven't found a way to identify what the various things are trying to do in order to know whether it's supposed to be able to do that or not.

So, while SELinux is not very difficult or complex in one sense, it can be very complex in a completely different sense.

For example:

type=SYSCALL msg=audit(1345667559.692:219271): arch=40000003 syscall=11 success=yes exit=0 a0=8a8f130 a1=8a8ad70 a2=8a8cd18 a3=40 items=0 ppid=938 pid=939 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ifconfig" exe="/sbin/ifconfig" subj=system_u:system_r:ifconfig_t:s0 key=(null)
type=AVC msg=audit(1345667559.692:219271): avc: denied { read write } for pid=939 comm="ifconfig" path="socket:[13363]" dev=sockfs ino=13363 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=tcp_socket


So, should I create a policy to allow this? Should I not audit this event at all? Will this break something if I set SELinux to Enforcing? I really don't know.

Try audit2why http://linux.die.net/man/8/audit2why to get some detailed msgs

If you want the syscall to succeed, yes.
Would have been better if you would have started your own thread for your own questions BTW.


Not if you want to know if ifconfig_t tries to do something in the initrc_t context.


Audit2allow returns "allow ifconfig_t initrc_t:tcp_socket { read write };" meaning ifconfig socket calls would fail during system boot, that is processes started in the initrc_t context AFAIK.

@unSpawn,

The purpose of my post was not necessarily to get answers to this issue it was to help jokar, the original poster, by giving an example of how SELinux can be complicated in one sense and not that complicated in another sense. The questions were rhetorical and meant to simply make the point that these are the things that need to be considered. That is why I did not create my own post for this issue...I wasn't seeking a solution, just sharing what I have found to be somewhat challenging with regards to why/when/how to determine of custom policies are needed.

In hindsight, I can see why it might have been perceived as attempting to hijack the thread, but I wanted to clarify that.

Ah, OK. I was only trying to see it as another question deserving an answer :-]