As I mentioned previously, recently my latest installment of "SELinux System Administration" has been released by Packt Publishing. This is already the third edition of the book, after the first (2013) and second (2016) editions have gotten reasonable success given the technical and often hard nature of full SELinux administration.
Like with the previous editions, this book remains true to the public of system administrators, rather than SELinux policy developers. Of course, SELinux policy development is not ignored in the book.
What has changed
First and foremost, it of course updates the content of the previous edition to be up to date with the latest evolutions within SELinux. There are no earth shattering changes, so the second edition isn't suddenly deprecated. The examples are brought up to date with a recent distribution setup, for which I used Gentoo Linux and CentOS.
The latter is, given the recent announcement of CentOS stopping support for CentOS version 8 in general, a bit confrontational, although it doesn't really matter that much for the scope of the book. I hope that Rocky Linux will get the focus and support it deserves.
Anyway, I digress. A significant part of the updates on the existing content is on SELinux-enabled applications, applications that act as a so-called object manager themselves. While quite a few were already covered in the past, these applications continue to enhance their SELinux support, and in the third edition a few of these receive a full dedicated chapter.
There are also a small set of SELinux behavioral changes, like SELinux' NNP support, as well as SELinux userspace changes like specific extended attributes for restorecon.
Most of the book though isn't about changes, but about new content.
What has been added
As administrators face SELinux-aware applications more and more, the book goes into much more detail on how to tune SELinux with those SELinux-aware applications. If we look at the book's structure, you'll find that it has roughly three parts:
- Using SELinux, which covers the fundamentals of using SELinux and understanding what SELinux is.
- SELinux-aware platforms, which dives into the SELinux-aware application suites that administrators might come in contact with
- Policy management, which focuses on managing, analyzing and even developing SELinux policies.
By including additional content on SEPostgreSQL, libvirt, container platforms like Kubernetes, and even Xen Security Modules (which is not SELinux itself, but strongly influenced and aligned to it to the level that it even uses the SELinux userspace utilities) the book is showing how wide SELinux is being used.
Even on policy development, the book now includes more support than before. While another book of mine, SELinux Cookbook, is more applicable to policy development, I did not want to keep administrators out of the loop on how to develop SELinux policies at all. Especially not since there are more tools available nowadays that support policy creation, like udica.
One of the changes I also introduced in the book is to include SELinux Common Intermediate Language (CIL) information and support. When we need to add in a small SELinux policy change, the book will suggest CIL based changes as well.
SELinux CIL is not commonly used in large-scale policy development. Or at least, not directly. The most significant policy development out there, the SELinux Reference Policy, does not use CIL directly itself, and the level of support you find for the current development approach is very much the default way of working. So I do not ignore this more traditional approach.
The reason I did include more CIL focus is because CIL has a few advantages up its sleeve that is harder to get with the traditional language. Nothing major perhaps, but enough that I feel it should be more actively promoted anyway. And this book is hopefully a nice start to it.
I hope the book is a good read for administrators or even architects that would like to know more about the technology.
One of the features present in the August release of the SELinux user space is its support for ioctl xperm rules in modular policies. In the past, this was only possible in monolithic ones (and CIL). Through this, allow rules can be extended to not only cover source (domain) and target (resource) identifiers, but also a specific number on which it applies. And ioctl's are the first (and currently only) permission on which this is implemented.
Note that ioctl-level permission controls isn't a new feature by itself, but the fact that it can be used in modular policies is.
A few days ago, Jason "perfinion" Zaman stabilized the 2.7 SELinux userspace on Gentoo. This release has quite a few new features, which I'll cover in later posts, but for distribution packagers the main change is that the userspace now has many more components to package. The project has split up the policycoreutils package in separate packages so that deployments can be made more specific.
Let's take a look at all the various userspace packages again, learn what their purpose is, so that you can decide if they're needed or not on a system. Also, when I cover the contents of a package, be aware that it is based on the deployment on my system, which might or might not be a complete installation (as with Gentoo, different USE flags can trigger different package deployments).
Yesterday I've switched to the gentoo-sources kernel package on Gentoo Linux. And with that, I also attempted (succesfully) to use the propriatary nvidia drivers so that I can enjoy both a smoother 3D experience while playing minecraft, as well as use the CUDA support so I don't need to use cloud-based services for small exercises.
The move to nvidia was quite simple, as the nvidia-drivers wiki article on the Gentoo wiki was quite easy to follow.
While still working on a few other projects, one of the time consumers of the past half year (haven't you noticed? my blog was quite silent) has come to an end: the SELinux System Administration - Second Edition book is now available. With almost double the amount of pages and a serious update of the content, the book can now be bought either through Packt Publishing itself, or the various online bookstores such as Amazon.
With the holidays now approaching, I hope to be able to execute a few tasks within the Gentoo community (and of the Gentoo Foundation) and get back on track. Luckily, my absence was not jeopardizing the state of SELinux in Gentoo thanks to the efforts of Jason Zaman.
A few days ago a vulnerability was reported in the SELinux sandbox user space
utility. The utility is part of the
policycoreutils package. Luckily, Gentoo's
sys-apps/policycoreutils package is not vulnerable - and not because we were
clairvoyant about this issue, but because we don't ship this utility.
While developing an init script which has to switch user, I got a couple of errors from SELinux and the system itself:
~# rc-service hadoop-namenode format Authenticating root. * Formatting HDFS ... su: Authentication service cannot retrieve authentication info (Ignored)
CIL is SELinux' Common Intermediate Language, which brings on a whole new set of possibilities with policy development. I hardly know CIL but am (slowly) learning. Of course, the best way to learn is to try and do lots of things with it, but real-life work and time-to-market for now forces me to stick with the M4-based refpolicy one.
Still, I do try out some things here and there, and one of the things I wanted to look into was how CIL policies would deal with interfaces.
If you're a bit following the SELinux development community you will know Dan Walsh, a Red Hat security engineer. Today he blogged about CVE-2015-4495 and SELinux, or why doesn't SELinux confine Firefox. He should've asked why the reference policy or Red Hat/Fedora policy does not confine Firefox, because SELinux is, as I've mentioned before, not the same as its policy.
In effect, Gentoo's SELinux policy does confine Firefox by default. One of the principles we focus on in Gentoo Hardened is to develop desktop policies in order to reduce exposure and information leakage of user documents. We might not have the manpower to confine all desktop applications, but I do think it is worthwhile to at least attempt to do this, even though what Dan Walsh mentioned is also correct: desktops are notoriously difficult to use a mandatory access control system on.
A nice twitter discussion with Erling Hellenäs caught my full attention later when I was heading home: Can SELinux substitute DAC? I know it can't and doesn't in the current implementation, but why not and what would be needed?
SELinux is implemented through the Linux Security Modules framework which allows for different security systems to be implemented and integrated in the Linux kernel. Through LSM, various security-sensitive operations can be secured further through additional access checks. This criteria was made to have LSM be as minimally invasive as possible.