

The SELinux coloring book [pdf] - adamnemecek
http://people.redhat.com/duffy/selinux/selinux-coloring-book_A4-Stapled.pdf

======
spydum
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.

~~~
csirac2
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?

~~~
SEJeff
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.

~~~
tgflynn
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 ?

~~~
csirac2
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.

------
TD-Linux
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.

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

~~~
nodata
Yes.

------
dnet
Reminded me of this diagram:
[https://grsecurity.net/~spender/pics/mac_security_sesamestre...](https://grsecurity.net/~spender/pics/mac_security_sesamestreet.jpg)

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

[https://grsecurity.net/compare.php](https://grsecurity.net/compare.php)

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

------
pivo
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/...](http://www.amazon.com/Bunnys-Guide-ActiveX-Carlton-
Egremont/dp/0201485362)

------
gvb
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...](http://blog.linuxgrrl.com/2014/04/16/the-selinux-coloring-book/)

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

