Most people don’t actually like real security as much as they claim they do. SELinux and its derivatives are pretty much the only real option we have for properly robust security these days.
If you are building a static system, SELinux is amazing. You need a few lines of policy per application to label things appropriately, then you can see what accesses programs made and decide if you want to allow them or not.
Taking a full Linux system and adding a locked down SELinux policy can be done in less than a week. If you are starting with an SELinux enabled system and just want to lock down your application, it can be done in less than a day.
Once you know what you are doing, there is also a pretty powerful policy analysis tool that lets you see what a given domain can do; including transitive things like “domain sandbox_t can launch a program in Domain vim_t, which can write a file in Domain sshd_config_t, which can be read by domain sshd_t” which may indicate that your sandbox has a hole allowing it to compromise your sshd configuration. Although, to be fair, doing this level of analysis is not simple, even with the tooling. And you very quickly notice issues that are inherent in how Linux works.
The problem with SELinux comes when you try applying it to general purpose systems, because you do not know ahead of time what the user will want to do. To be effective, policy needs to be written for the specific system it will be running on.
An example I like to use is Android. Android makes great use of SELinux, and is a general purpose system. But the SELinux policy itself does not protect the general purpose Android system. It protects the special purpose system that is the Android runtime. All apps run with the same policy that says things like “cannot access the filesystem at all, unless given access by the Android runtime”, then the actual security policy users see is all implemented in use space by Android. SElinux is just a means of preventing apps from bypassing the Android permission system.
I like the fact that it is a solid mandatory access control system. With SELinux you are substantially more safe than without.
For example. Let’s say you are running a compromised version of OpenSSH. Threw a XZ style back door a hacker gets in as OpenSSH (which runs as root).
Without SELinux the system is fully owned. With SELinux the attacker can only access what OpenSSH needs to access even if they have root. They can’t just chmod files and folders wherever. That means your photos and application data are still secure. With the pre written SELinux policies this applies not just for OpenSSH but for every piece of software installed on your system. Everything is limited to the exact folders, ports, and system capabilities that it needs and no more. Even stuff like seperate websites being served under Nginx. You can have Nginx-subgroup-1 and Nginx-subgroup-2 where the applications can’t see each other even though they are being run as the Nginx user.
I don’t trust any Linux distro without this security layer.
It’s a little difficult to learn and master, but it’s totally worth it if you care about security.
you’re the first person i’ve ever heard of who liked selinux; what do you like about it?
Most people don’t actually like real security as much as they claim they do. SELinux and its derivatives are pretty much the only real option we have for properly robust security these days.
If you are building a static system, SELinux is amazing. You need a few lines of policy per application to label things appropriately, then you can see what accesses programs made and decide if you want to allow them or not.
Taking a full Linux system and adding a locked down SELinux policy can be done in less than a week. If you are starting with an SELinux enabled system and just want to lock down your application, it can be done in less than a day.
Once you know what you are doing, there is also a pretty powerful policy analysis tool that lets you see what a given domain can do; including transitive things like “domain sandbox_t can launch a program in Domain vim_t, which can write a file in Domain sshd_config_t, which can be read by domain sshd_t” which may indicate that your sandbox has a hole allowing it to compromise your sshd configuration. Although, to be fair, doing this level of analysis is not simple, even with the tooling. And you very quickly notice issues that are inherent in how Linux works.
The problem with SELinux comes when you try applying it to general purpose systems, because you do not know ahead of time what the user will want to do. To be effective, policy needs to be written for the specific system it will be running on.
An example I like to use is Android. Android makes great use of SELinux, and is a general purpose system. But the SELinux policy itself does not protect the general purpose Android system. It protects the special purpose system that is the Android runtime. All apps run with the same policy that says things like “cannot access the filesystem at all, unless given access by the Android runtime”, then the actual security policy users see is all implemented in use space by Android. SElinux is just a means of preventing apps from bypassing the Android permission system.
I like the fact that it is a solid mandatory access control system. With SELinux you are substantially more safe than without.
For example. Let’s say you are running a compromised version of OpenSSH. Threw a XZ style back door a hacker gets in as OpenSSH (which runs as root).
Without SELinux the system is fully owned. With SELinux the attacker can only access what OpenSSH needs to access even if they have root. They can’t just chmod files and folders wherever. That means your photos and application data are still secure. With the pre written SELinux policies this applies not just for OpenSSH but for every piece of software installed on your system. Everything is limited to the exact folders, ports, and system capabilities that it needs and no more. Even stuff like seperate websites being served under Nginx. You can have Nginx-subgroup-1 and Nginx-subgroup-2 where the applications can’t see each other even though they are being run as the Nginx user.
I don’t trust any Linux distro without this security layer.
It’s a little difficult to learn and master, but it’s totally worth it if you care about security.
Redhat put out a comic about it a few years ago explaining the basics. https://people.redhat.com/duffy/selinux/selinux-coloring-book_A4-Stapled.pdf