What is SELinux and what can it do for you? In this week’s Vblog, Dan Goodman dives deep into all things Linux Security, what it can and can’t do for you as a user and the process of implementation in your system. (scroll down for video)
SELinux: The Basics and What it Provides
SELinux, in a nutshell, plugs up holes that are left by discretionary access controls and implements Mandatory Access Control (MAC). Many times we take this for granted and forget all that it is doing for us behind the scenes! Key things: SELinux is enabled by default and will check for allowed operations after the standard discretionary access controls are checked.
What we get:
Think of this system and elements as a pyramid. At the top point, we have our Discretionary Access Controls (DACs). Everything else is going to piggy-back off of these and make up the remainder of the pyramid underneath (see picture below). These elements are standard permissions on any resource (file or individual directory). So under our DACs we could have a firewall, SELinux-MAC, Access Control Lists, special attributes and things that prevent users from deleting a file. All of these elements exist to support the DACs. SELinux is not intended to over rule these, rather, it will consult the DACs for permissions first.
A True Implementation of Mandatory Access Controls (MACs)
MACs Compliment DACs
MACs is the key thing that we get with Security Enhanced Linux. A true implementation of this is really going to compliment the DACs. The standard permissions don’t really have a way to accommodate services, poor information, or a variety of network based scenarios. This is because they are based on three criteria: you are either A) the owner, B) a member of the group who owns that resource or C) you fall into the “other” category.
Objects: files, directories, devices
Subjects: processes. For example, command execution or running applications
Context: a combination of all the labels the ultimately define the security-related information because SELinux implements role-based access control, type-enforcement, and a variety of other things that are not included with the standard permissions on our system
Domain: a way to organize all of these processes that tend to share certain characteristics. Through these domains we can really control what processes interact with other processes.
First, SELinux is a distinct separation of services. All the process and files will be labeled with a type. Those process types are organized into domains. Similar files also get organized together. The processes ultimately run in their own domain with various policy rules that define how they can interact with certain file types and processes both inside and outside the domain. If we don’t have a way to look at processes, that’s where SELinux comes in.
Second, SELinux definitely provides a much more granular level of access control. The standard permissions go all the way back to the early days of Unix. While they are still effective and SELinux makes it readily available and are there to support those permissions, obviously something more robust is required. Time to bring out the big guns. The SELinux access decision is based upon ALL available information about a user, process, port information etc.
SELinux also gives owners of resources on any system the power to define access to those resources. In other words, resource owners ultimately define access to their own resources. The SELinux policy settings apply to the entire system including the inner process communication and are not modifiable by the average user. The best part? This is all labeled by default! It’s working behind the scenes and we don’t even realize it!
SELinux is NOT antimalware and it’s NOT a replacement for other security mechanisms. It’s intended to plug the holes left by others. And it’s definitely NOT an all encompassing security solution. All forms of security should be used together– SELinux, access control lists, etc. because they each address certain areas of security. Again, SELinux is designed to enhance existing security solutions, NOT replace them. For more on Cybersecuirty with a Linux operating system, check out Dan’s Vblog of with all you need to know here.
The Play Book
At boot time, the Linux Kernel will start up along with the SELinux Module. The SELinux module essentially creates a funnel that everything has to pass through. By having that firm relationship with the kernel, they are there working with each other. The SELinux policy primarily comes in two different policies. The targeted policy is installed by default and will be used on pretty much all distributions. Even though there is a custom option, it’s best practice to take the targeted policy and modify it accordingly. The targeted policy has a number of default settings, but everything is ultimately a bullion value. You can set this to enabled or disabled.
The SELinux Mode primarily comes in three varieties: enforced, permissive, disabled. With disabled, the DACs are the only mechanism in play and primary tool at your disposal. Permissive is in the middle of enforced and disabled and is primarily used as a trouble shooting tool. What it does for you is it allows what would normally be blocked by SELinux. All of those “would-be-denials” would be logged in the appropriate location for SELinux. Technically, it takes whatever the policy says, however, it’s not going to deny a particular activity from occurring. Enforcing is exactly what it sounds like. The SELinux policy is enforced, SELinux will deny access based upon policy rules.
Let’s say any process- anything someone does on their system- is put into the system. The first thing that is consulted is the Discretionary Access Control (DAC). If this results in denial, SELinux doesn’t even come in to play. The permission said no, so SELinux will not take action. If the permissions allow, SELinux will intercept that process and force it through the funnel of the SELinux module. If SELinux goes into a decision of it’s own, all decisions will be stored as Access Vector Cash (AVC) messages. As these processes rinse and repeat, AVCs stop them from having to go through the entire wheel. It cashes those previous denials and approvals to speed up the process each time moving forward. If SELinux denies, the operation is blocked and the process will receive an error. Something to note: as SELinux is making it’s decision, it implements a default, deny. If a policy rule does not specifically allow, the operation will automatically deny.
Want to become a more efficient IT team with Agile Methodology? Learn how to increase your organizational efficiency in less than an hour with StormWind Senior Instructor Ashley Hunt Quickcast on December 13th!
Loved this video? Hated it? Tell us! We want to know! Add a comment at the bottom of this page with your ideas for next week’s VBlog! What do you want StormWind to talk about?