The SELinux coloring book [pdf] | Hacker News Reader

The SELinux coloring book [pdf]

people.redhat.com

86 pointsadamnemecek17 comments

I find SELinux is a very cool feature, if I really needed fine grain control over my system.

Reminded me slightly of facls under Solaris, just far more elaborate. At least at the time of RHEL5 -- the tools around it were just too rough for even intermediate admins to manage (I have not revisited since then).

Even then, if I really was concerned about compartmentalization, might I turn to containers and/or virtualization, just for the simplicity of it.

Nowadays, it's mostly just another thing to check disabled when installing RHEL -- very few external apps/packages seem to understand it, and predicting all the interactions and establishing labels/types is just a bridge too far. Yes, I know you can use selective mode, or even permissive then build policies based on the audit logs, and If I ran a NSA storage subsystem, I might be bothered to.. but for most folks, this level of scrutiny is too cumbersome.

Assume an environment where VMs are already used for rough isolation... If we wanted to further lock down VM guests (and hosts for that matter), and SELinux is too cumbersome - does AppArmor or grsecurity strike a significantly better balance between usability and effectiveness? Is there something else?

If you are using SELinux and libvirtd, the sVirt integration between the two automatically keeps one vm from attacking another vm should there be a way to compromise the host kernel.

If the host kernel is compromised (where I assume SELinux is running in this scenario) wouldn't that render SELinux itself suspect. It seems like SELinux's integrity must be dependent on that of its own kernel, or have I misunderstood the scenario you describe ?

There have been at least a few kernel privesc vulnerabilities, for example, which have apparently been mitigated successfully with SELinux (I assume that the SELinux policies prevent the necessary pre-conditions of the exploit being met, like denying certain ioctls etc. before they can do damage). I guess it depends on the nature of the exploit.

In any case it sounds like libvirtd can automatically assign a unique category to each VM guest's resources in a way which inhibits guest-to-guest interactions by default.

No you understood it correctly. There are several kernel exploits that involve things like sending nasty ioctls, opening raw devices, reading/writing to /dev/mem, etc that SELinux will mitigate when it is enforcing mode. It is not a catch-all by any means, but defense in-depth involves multiple layers. SELinux has demonstrably prevented local privilege escalation 0days from working.

Edit:

More Info: https://www.redhat.com/archives/libvir-list/2008-August/msg0...

I recently needed to confine a java application running in Ubuntu VMs. Although apparmor documentation was more scattered than I expected, I was able to go from never having used it to a working profile in a little over a day. There weren't many new concepts involved, the profiles were easy to read and write, and although the tools has some rough edges they did help me develop and verify my profile.

> SELinux is too cumbersome.. does AppArmor or grsecurity strike a significantly better balance between usability and effectiveness?

You get this out of the box with SELinux. It's either zero extra work or you tick a box.

audit2allow and friends have really come a long way since SELinux's introduction. I have a RHEL7 virtual machine running a node app and it works really well. If permission is denied for something, I just look at the audit log to see if it was selinux's fault, then audit2allow will either tell me what permission I need to turn on, or give me a custom rule to allow that behavior.

Does audit2allow suggest appropriate labels e.g. "this file cannot be written to. ...._t might be a more appropriate label for it" ?

Yes.

Reminded me of this diagram: https://grsecurity.net/~spender/pics/mac_security_sesamestre...

Thanks for that. One of the first things that came to mind for me was under the same domain:

https://grsecurity.net/compare.php

I have nightmares about the kernel penguin in this coloring book.

This reminds me of a book a friend of mine wrote years ago called, "Mr Bunny's Guide to ActiveX" which I believe originally came with crayons, or at least that was his intention.

http://www.amazon.com/Bunnys-Guide-ActiveX-Carlton-Egremont/...

Máirín Duffy's blog post on the book with the background, two formats, source, licensing, etc.

http://blog.linuxgrrl.com/2014/04/16/the-selinux-coloring-bo...

Why does Tux have to be so evil-looking in this coloring book?

Reply on news.ycombinator.com