This transcript is from StormWind Studios’ Vblog: All Things SELinux
Hey there, folks. Welcome to our next entry in the Linux Security blog, if we want to call it that, focusing on all things basic security pretty much across the board when you’re talking about any distribution of Linux.
In the first video we put together, we really looked at security from an overall perspective, just highlighting some of the key areas, the standard Discretionary Access Controls that we get with the Read, Write, and Execute permissions, Access Control List, the firewall service, and then Security Enhanced Linux. In fact, that’s what we want to focus on here is SELinux basics discussion, really focusing in on why I think it’s a very useful tool, even though it tends to have a bad rap in certain environments, just because a lot of folks don’t take the time to go through and really fine-tune it to make sure that it’s going to allow what you need it to allow and deny what you want it to deny, just like anything else, just like a firewall, just like an Access Control List. We want it there. We should modify accordingly.
The first thing that we want to circle back to is the infamous pyramid I put together, or terrible pyramid, however you want to describe it, just recognizing that everything that we talk about is going to support the standard permission. So, at the top of our pyramid, we’ve got our Discretionary Access Controls, AKA Read, Write, and Execute, what we’ve seen a million times, but underneath that to plug some of the holes left by the Discretionary Access Controls would be things like Access Control List. Of course what we’re going to talk about today would be SELinux. Then you could have the firewall in there, and then a variety of other network-based services. We want to focus on this aspect because even though the Discretionary Access Controls are very effective at what they do, they’re not an all-encompassing solution. They don’t have a setting. They don’t have a permission, even if we take advantage of the special attribute permissions. They’re not an end-all-be-all solution, which is why we have these other mechanisms in place.
So, with Security Enhanced Linux, the key thing that we get is what we call a “Mandatory Access Control”, a true implementation of Mandatory Access Control that is really going to complement the Discretionary Access Controls because if we look at it from a very high-level point of view, the standard permissions really don’t have a way to accommodate services. They don’t have a way to accommodate port information. They don’t have a way to accommodate a variety of network-based scenarios, even process-to-process communication because they are based upon three primary criteria. You are either the owner, you are a member of the group who owns that resource, or you fall into the Other category.
Well, what if you don’t want to give a service, like a patchy web server, access to everything else on your system because, technically, they would get lumped into that other category. Or, name any other service out there. They would technically fall into that Others category, and of course that opens us up to a wide range of problems if those services ever get exploited.
So, some of the key terms that we have with SELinux … Everything kind of has their own terminology, whether you’re talking about firewalls, Access Control Lists. Well, with SELinux, they with SELinux, they just have these different terms to refer to things that we’re used to seeing. When we’re talking about files, directories, various devices, those tend to be Objects. The Subject would be processes themselves. Could be something as simple as executing a command or running an application. The Context is essentially a combination of all the labels that ultimately define the security-related information because SELinux implements role-based access control, type enforcement, and a variety of other things, once again, simply not included with the standard permissions on our system. The Domain is a way to actually organize all of these processes that tend to share certain characteristics. Through these domains, we can really control what processes interact with other processes.
Now, this is all well and good, but what does that ultimately boil down to? What I like to say with SELinux is, “What it do? What it don’t do?” Well, the first, “What does it do?” Or, “What it do.” We’ll just talk like that. “What it do.” It’s a distinct separation of services. All the processes, all the 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 domains with various policy rules that define how they can interact with certain file types and processes both inside and outside of the domain. Once again, that’s simply something you don’t get even with an Access Control List because we’re talking about, what, IP address host name? We don’t have a way to look at processes. That’s where SELinux comes in.
Definitely a much more granular level of access control. The standard permissions go all the way back to the early days of units. While they are still effective and while SELinux makes it readily available that they are there to support those permissions, obviously something more robust is required. Now, the SELinux access decision is based upon all available information about a user, about a process, about a process talking to another process, port information, once again, simply something we don’t get with the standard permissions.
Another thing that we may or may not realize is all of those owners of all those resources on any system, they are the ones who ultimately define access to those resources. Yeah, the root user, yeah the administrator vote user can go in and fine-tune certain things, but at the end of the day, there is no administratively-defined policy, unless we take advantage of SELinux. Resource owners ultimately define access to their own resources, even if you throw in the umask value, it’s still the standard permissions. The SELinux policy settings apply to the entire system, including the inner process communication, and they’re not modifiable by the average user. The other thing that we get is it’s enabled by default. It’s almost something that we don’t even realize is working behind the scenes.
So, with a firm understanding of “what it do”, what about “what it don’t do”? Well, it’s not anti-malware. It’s not a replacement for other security mechanisms. There is definitely an order of operations, so to speak, when it comes to determining who has access, or, in some cases, what has access because we’re talking about processes and port information and network services. So, it’s not a replacement for any other security mechanism. It’s intended to kind of plug the holes left by others, and it’s definitely not an all-encompassing security solution. What I don’t want you guys to do, not that you would do it, but don’t watch this video and say, “Ah, I’m never using standard permissions. I’m an SELinux person now, or I’m an Access Control List person now.” No. All of these should be used together because they address certain areas of security. SELinux, once again, is designed to enhance existing security solutions, not replace them.
What I want to close with here is just a standard architecture overview of what SELinux does, whether it’s a user accessing a resource, whether it’s a process accessing a resource, one process talking to another process. I apologize in advance that this kind of resembles an NFL-level playbook, but this is the complexity, so to speak, for lack of a better term really, because once you see it in action, this almost becomes second nature.
At boot time, of course the Linux kernel is going to start up, the SELinux module is a kernel module that gets loaded at boot-time. It essentially creates a funnel that everything has to pass through, every process, every request to to access a resource. By having that firm relationship with the kernel … It’s almost a Batman and Robin, Burt and Ernie scenario. They’re there working with each other. The Linux Security module is built into the Linux kernels. It’s loaded at boot-time. The SELinux policy primarily comes in two different varieties. The targeted policy is installed by default, and it’s pretty mch the one that’s going to be used on all distributions out there.
Now, even though there is a custom option, one thing I like to caution everyone is that, technically, administrators can define their own policy. However, it’s definitely a best practice, it’s definitely a recommendation, to take the targeted policy and modify it accordingly because the targeted policy has a number of default settings, but everything is ultimately a Boolean value. You set it to enabled or you set it to disabled. There’s only two options with it.
So, one of the examples that you might want to consider doing is to allow or disallow the sharing of home directories via Apache or Samba. If the policy says, “Disabled”, then that means we are not going to share those directories, but if it is, it’s only going to allow Apache or Samba to access home directories of users on a local system.
Now, with the SELinux mode, it primarily comes in three varieties: Enforced, Permissive, and Disabled. Disabled is pretty much what you’d expect it to be. The key thing with Disabled is that the Discretionary Access Controls are the only mechanism in play. Of course, if you had other elements working, the firewall, the Access Control List, but to clarify, the Discretionary Access Control would be the primary tool we have at our disposal. Permissive is kind of a go-between between Enabled and Disabled because what it does for you is what would normally be blocked by SELinux would be allowed. All of those would-be denials are logged in the appropriate location for SELinux, so it’s primarily used as a troubleshooting tool. It technically takes whatever the policy says; however, it’s not actually 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 the policy rules.
Let’s just say down here … What I’ve tried to do here is show you the three different streams of information, so to speak. Let’s say it’s any process, anything that somebody does on their system, the very first thing that gets consulted is, of course, the Discretionary Access Control. Simply put, if the Discretionary Access Control results in a denial, SELinux doesn’t even come into play. It’s basically going to say, “Hey, the permission said, ‘No.’ I’m not even going to do anything. The permission said, ‘No.'”
Now, if the permissions allow, SELinux will intercept that process, force it through this funnel of the SELinux module. Everything passes through that module. Now, let’s say that SELinux goes into a decision of its own. All decisions will be stores as AVC messages, Access Vector Control … Cache, let me get that out correctly … Access Vector Cache messages, because as these processes rinse and repeatedly, we don’t have to go through the entire wheel. It caches those previous denials and caches the previous approval to speed it up each time going forward.
But let’s just say that SELinux is going to allow an activity to occur. It does exactly what we’d expect it to. The activity would occur, and we’re none the wiser. Now, if SELinux denies, the operation is blocked and the process will receive an error. Now, another thing to throw in here is as SELinux is making it’s decision, it definitely implements a default deny. If a policy rule does not specifically allow, the operation will automatically deny. That’s obviously different than a default allow, which is definitely what we don’t want.
One other thing I definitely want to close off with this, is just because SELinux … It doesn’t truly do nothing, in the truest sense of the term. Let’s say that even though the permissions say, “Yes,” one of the things that SELinux is going to do is it’s going to look at the process of accessing that resource. The permissions may not have a specific entry for that process, but if you think about it, a lot of the services that we add on the system, they’re going to create a system-specific user, so there is going to be an Apache user. There would be a Samba user that gets created. Shoot, if you install a DNS server, there’s going to be a BIND user that gets created. Most of those users would fall under the Others category, which, more often than not, is going to grant at least Read access, so we get back to the allow section and ultimately, everything in some way, shape, or form, is going to process through SELinux. SELinux, let me say that correctly.
Hopefully, this provides you with a little bit of insight. Next time, we’re going to run a Go route, going down the 50 yard line, and cut across here, but definitely a useful feature that you don’t want to make the mistake of disabling altogether because I’ve seen a lot of stories out there where folks will say, “I’m in development or doing some troubleshooting. Just disable SELinux.” It’s not … How do I say this nicely without trademark infringement or anything like that? It’s not like the Schmindo’s firewall where it’s usually just easier to disable it than try and troubleshoot it. So, don’t lump it into that same category of the Schmindo’s firewall because it’s a lot more robust. It is definitely something that you want to take the time to fine-tune, to allow what you want it to allow, to deny what you want it to deny.
Alright, folks. Hopefully, this was insightful. We’ll probably do a couple more of these, focusing on the different areas of Linux. This was all about security. Hopefully it was beneficial for you guys. Go ahead and sign off here, and I’ll talk to you guys soon. Take care.
This transcript is from StormWind Studios’ Vblog: All Things SELinux