Today we’re going to talk about SELinux – Security-Enhanced Linux. For the everyday layman, SELinux may be daunting to set up but is a good introduction to different ways to manage access control to your systems. More and more we give companies our precious data and the onus should be placed on developers to protect this data from growing cybersecurity threats.
What is SELinux?
SELinux stands for Security-Enhanced Linux. It is a labeling mechanism to provide high security to files and other objects in the system from unauthorized processes and also authorized processes that do not have or need such access to avoid misuse.
One can install SELinux in any existing Linux system. This usage will not be useful for all individual users but is essential for server systems.
Its security rigidness can be understood by the fact that with SELinux, a root-owned process even if hacked can’t access the files that are not given access.
How does SELinux work?
SELinux defines access controls for the applications, processes, and files on a system. It uses security policies, which are a set of rules that tell SELinux what can or can’t be accessed, to enforce the access allowed by a policy.
When an application or process, known as a subject, requests to access an object, like a file, it checks with an access vector cache (AVC), where permissions are cached for subjects and objects.
If SELinux is unable to decide access based on the cached permissions, it sends the request to the security server. The security server checks for the security context of the app or process and the file. The security context is applied from the SELinux policy database. Permission is then granted or denied.
If permission is denied, an “avc: denied” message will be available in /var/log.messages.
Drawbacks of Disabling SE Linux
On disabling SELinux, each process will have access to files as in a normal Linux System. Misuse of rights cannot be prevented. A hacked process can gain access to secret files which are not needed for their original purpose and might be misused. This is a serious issue.
If a process with root permission is compromised, then the entire system is at risk. What SELinux provides is more rigid security.
Why would you want to disable SELinux if it’s a security feature?
Because often extreme security features become a pain. The same is true for SELinux.
Because it is way too strict on what files are accessible by what process, you’ll have a hard time making various services work properly on your server.
For example, if files in /var/lib are owned by root and with file permissions 000, the program that requires these files won’t run.
Also, when you are debugging an application, SELinux becomes a pain. Disabling it saves you headaches.
There are three modes: Enforcing, Permissive and Disabled.
- Enforcing mode is the default mode at the installation of SELinux. It will enforce the policies on the system, deny access and log actions.
- Permissive mode is the most commonly used mode for troubleshooting SELinux. In this mode, it enables but does not enforce security policies. Also, this means that actions will result in a warning and log for the system administrator.
- Disabled mode means that SELinux is turned off and the security policies do not protect the server.
How to handle SELinux errors?
When you get an error in SELinux there is something that needs to be addressed. It is likely 1 of these 4 common problems:
- The labels are wrong. If your labeling is incorrect you can use the tools to fix the labels.
- A policy needs to be fixed. This could mean that you need to inform SELinux about a change you’ve made, or you might need to adjust a policy. You can fix it using booleans or policy modules.
- There is a bug in the policy. It could be that a bug exists in the policy that needs to be addressed.
- The system has been broken into. Although SELinux can protect your systems in many scenarios, the possibility for a system to be compromised still exists. If you suspect that this is the case, take action immediately.
SELinux essentially acts as a sandbox protecting your information from fraudulent or corrupted access by external programs or daemons. It is better for those who are very familiar with Unix-based systems. It is a great way to implement security, but it is known for its bugs and disruptive mechanisms. Actual sandboxing is another alternative to protecting your kernel.