Linux 4.7 was released almost two weeks ago, but due to some travel I haven’t had any time to write up the usual release notes. However, I did manage to find a few minutes, so without further delay I present to you the SELinux and audit highlights in the latest Linux Kernel major release.
SELinux
Add the ability to restrict kernel module loading via the new “system:module_load” permission.
Distinquish between the init and non-init user namespaces when performing capability checks. The init namespace uses the existing “cap” and “cap2” object classes while non-init user namespaces use “cap_userns” and “cap2_userns”.
Apply the “process:execstack” check to thread stack’s allocated via mmap().
Audit
Add the terminal information to the LOGIN record via the “tty” field.
I’ve never been a fan of GRUB2, I much prefer the simplicity of GRUB Legacy, and as a result I never spent much time learning how to configure it; I simply hacked away at the configuration and asked Google for help when needed. However, while debugging a kernel problem last week I finally reached my breaking point and decided it was time for me to develop a proper GRUB2 configuration that met my needs better than the Fedora Rawhide defaults. The resulting /etc/default/grub file is shown below:
Before I explain the lines above I want to make a quick comment about grubby, the tool used by Fedora (perhaps others?) to update the GRUB2 configuration when new kernels are installed. It appears, at least at the time of writing, that grubby does not honor the /etc/default/grub configuration file and may not generate a GRUB2 boot loader file that is consistent with the desired configuration. My workaround is to simply run the following command after a new kernel has been installed, it will regenerate the GRUB2 boot loader file based on the configuration in /etc/default/grub :
# grub2-mkconfig -o /boot/grub2/grub.cfg
Now let’s cover the GRUB2 configuration above, line by line. The first line disables the submenu and places all boot loader choices in the top level menu.
GRUB_DISABLE_SUBMENU=yes
The line below sets the timeout before the default boot option is chosen.
GRUB_TIMEOUT=20
The line below is a Fedora default that I’ve largely ignored as it doesn’t have any impact on what I’m trying to do with my systems.
The line below is a list of parameters to pass to the kernel at boot. Most of these are, or were, Fedora defaults at some point with the exception of “nomodeset”, which disables the kernel graphics modesetting, and “console=ttyS0”, which sets the console to the first serial port.
The line below disables the creation of a recovery kernel image and associated boot loader option. Although be warned that even though this will prevent GRUB2 from creating a new recovery kernel image, you may need to manually remove any previously created recovery kernel images in order to remove the recovery kernel from the boot loader option list.
GRUB_DISABLE_RECOVERY=true
The line below instructs GRUB2 to reference partitions by their device name/path and not their UUID, e.g. use root=/dev/sda1 instead of root=UUID=<xxx> .
GRUB_DISABLE_LINUX_UUID=true
That’s my GRUB2 configuration. There are plenty of other good references online, Google is your friend of course, but if you like a simple boot loader configuration with a serial console, I encourage you to check out the config above, it works pretty well.
UPDATE: In order to completely remove the recovery/rescue kernel you also need to instruct Dracut not to generate a rescue kernel and initrd. This can be done by creating the /etc/dracut.conf.d/02-rescue.conf file with the following contents:
dracut_rescue_image="no"
This will prevent Dracut from creating rescue images when new kernels are installed on the system.
Today I was sent a link to a blog entry where the author made the claim that in his opinion SELinux is beyond saving. From reading the entry, and those linked from it, it appears that the main argument revolves around different usability aspects: understanding, troubleshooting, and configuring SELinux. He goes on to suggest OpenBSD’s pledge(2) mechanism as an alternative to SELinux.
As you can imagine, I disagree quite a bit with that blog, although I do agree that there is still work that can be done to improve usability, especially on systems where users have added heavy customizations. This is an area where we continue to work to improve, and I think we’ve come a long way since our humble beginnings in Fedora Core 2, over 12 years ago. If you are interested in helping contribute, or are having problems with SELinux that you can’t resolve, I would encourage you to reach out to the SELinux community. If you aren’t sure who to contact or where to start, I’ve included some links below which should be helpful; you can also contact me via @securepaul.
I’m also not the only who feels this way, I’m seeing more users enabling SELinux, and more software developers starting to look at writing SELinux policy for their applications. Not to mention Android and the SEAndroid project. Starting with Android 4.4, SELinux has been a required part of Android, and with over 75% of all active Android devices running at least 4.4 (as of May 2016) there are millions (billion?) of SELinux systems in people’s hands.
Finally, a quick word about SELinux and mechanisms such as OpenBSD’s pledge(2) and Linux’s seccomp. SELinux is an access control mechanism, it is designed to restrict users and applications to only those resources on the system to which access has been explicitly granted. SELinux provides the ability to selectively allow access to individual files, devices, communication channels, and other resources. Security mechanisms such as pledge and seccomp are designed differently from SELinux; instead of focusing on access control these mechanisms focus on protecting the kernel from exploited applications by disabling portions of the kernel. Where SELinux can prevent an application from accessing a sensitive file while still allowing other file accesses, pledge/seccomp disable access to the kernel’s file I/O mechanisms preventing an exploited application from escalating by exploiting a kernel bug. To borrow an old analogy, trying to replace SELinux with pledge/seccomp, or pledge/seccomp with SELinux, is like trying to replace apples with oranges; they just aren’t the same. However, while they may not be replacements for each other, they do compliment each other nicely and a system that makes use of both SELinux and pledge/seccomp can provide a nice measure of protection for both the system’s data and the system itself.
