Picture of Paul Moore

Paul Moore

© 2024 Licensed under CC BY-NC-SA 4.0

Observations on SELinux

27 May 2016 tags: seccomp selinux

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.

Latest Posts