Transcript from the Linux vBlog video:
Hey there, folks. Welcome to our video blog on Security from a Linux+ Perspective if we want to call it that. One of the great things that I like about Linux is, of course, the security that it provides to us. It’s not to say that other operating systems out there are any less secure, or more secure, I just kind of take the facts as they are, you don’t really hear a lot about Linux compromises, Linux malware, those sorts of things. I think they’re doing something a little bit better than, let’s just say, the other operating systems out there in the world.
I really think that’s because Linux implements various aspects of security that are intended to complement each other as opposed to contradicting each other. I think in that regard it’s very similar to a unified threat management system. Instead of looking at everything and kind of “Well, anti-malware software does this, and firewalls do this, and permissions do that.” Linux kind of recognizes that “You know what, permissions solved 99% of the issues, but for that 1%, we’re going to divide that 1% up against other mechanisms that are going to fill that tiny gap that’s left by the standard permissions.”
What I’ve kind of put together is kind of how these different pieces fit together. I drew this ahead of time because I have terrible handwriting on this thing, but normally I describe this as kind of the Linux security pyramid, for lack of a better term, but obviously a pyramid comes to a point, so I kind of like to think of this as the Linux Lego blocks, if we want to call it that, maybe the Linux bricks of security.
That’s because everything is built upon the standard permission set, it’s called the user, group, other permission set. UGO Permissions technically implement what’s called discretionary access control permissions, based upon who you are, that determines what access you have to a particular resource.
The key thing to keep in mind in a Linux operating system is that regardless of what you’re talking about, it could be the kernel, it could be a configuration file, it could be a driver file. They’re all text files. Obviously, some of these text files are more advanced, more complicated than other text files, but they are still text files, which is why the standard permissions are kind of the foundational brick. I like to consider them as kind of like the standard Lego brick, it’s 2×6 or 2×4, and from that, you can build everything on top of that, those are where the discretionary access control permissions come into play.
The way I like to remember these permissions is kind of how I grew up. If mom said no, it didn’t really matter what dad said, mom said no. But if mom said yes, I also had to check with dad. If I wanted to go out on a Friday night or spend the night at somebody’s house. That’s kind of how the permissions work.
Those permissions, if they say no, if they say “You don’t have read and write permissions, you don’t have executable permissions.” It really doesn’t matter what the other mechanisms say, the standard permissions say no. The other mechanisms kick in when the standard permissions say “You do have read access, you do have write access.” I kind of broke this down into the red bricks, representing what happens on local users of the system, the blue bricks represent what happened to users outside of the system.
The UGO Permissions are pretty much what you’re used to seeing on every operating system out there, read, write and execute permissions. Those permissions can be defined according to user. The U in UGO is somewhat misleading, U stands for the owner of the resource. If you think about it, UGO sounds a little bit more catchy than OGO, OGO permissions. The U in UGO stands for the owner of the resource. As you would expect, the owner of the resource can pretty much do whatever they want to, it’s their resource.
G obviously stands for group, the group that is responsible for that resource. Obviously, we can define multiple groups, and multiple groups can have access to a particular resource. Then, the O stands for other, basically, everybody who doesn’t fit into column one or column two, the other category it’s a catch-all category, and each category can have their own permission set of read, write and execute.
Now, let’s kind of continue with that analogy, let’s say that the permissions say “You do have read access to a particular resource” or “You do have write access to a particular resource.” That’s where dad comes into play, or that’s where the supporting mechanisms will kick in.
PAM stands for Pluggable Authentication Module. The best way to describe it is that it’s a common framework for authentication for particular applications on our system. Kind of think about applications on other systems, or even think about an app on your smartphone. Some apps use one particular set of criteria, they have their own username and password, sometimes you have to enter a [inaudible 00:05:44], sometimes you have to do a finger pattern on your keyboard. The problem that you run into there is everybody kind of implements authentication differently, some are good, some are bad.
With Pluggable Authentication Modules, everybody kind of subscribes to the same idea of these authentication mechanisms are robust, they’re going to accomplish what we want to accomplish, they’re going to verify the user is who they claim to be, they’re going to deny folks who don’t pass that authentication test, it is a universal framework of sorts for application authentication.
The next thing that kicks in, and once again, the red represents what happens on the local system, is SELinux, Security-Enhanced Linux. Whereas the UGO Permissions are discretionary access control, SELinux implements what’s called mandatory access control, or MAC. If you think about it, UGO Permissions are dependent upon who you are, you’re either the owner of a resource, you’re a member of a group that has access to that resource, or you’re somebody else. SELinux looks at it from a different perspective and says “I don’t care who you are, this is the type of data, this is the sensitivity of the data, this is what you’re trying to do to that data regardless of who you are.”
SELinux really kicks in a very common example of what’ll see is when a standard application attempts to access a non-default directory for that particular application. A great example of that is an Apache web server, by default, Apache is configured to share out webpages from their www directory.
Most web developers will actually create websites in a non-default directory. It could be a user’s home directory, it could be a centralized storage location. SELinux is going to look at it and say “Wait a minute, I know Apache web server uses port 80 and it’s supposed to access the var/www directory, this particular user is attempting to share out a website from a non-default directory, I’m going to air on the side of caution and say ‘I’m not going to allow that to occur’.”
SELinux really kind of takes out the user element and implements a standard set of permissions that basically says “regardless of who you are, this is what you’re trying to do, this particular piece of data has this sensitivity level associated with it, I’m going to air on the side of caution more often than not,” label that resource accordingly and not allow you to do that activity.
SELinux, just like the permissions, can be modified, but a lot of times our issues, for lack of a better term, with SELinux is we get an unexpected result. I used that example of Apache web server accessing a non-default directory because that’s a very common issue we run into, a lot of us will create resources in non-default directories, SELinux is going to kick in as one additional security mechanism and say “this doesn’t look normal so I’m going to deny that from occurring.”
The blue bricks are intended to represent things that are for users outside of the system, obviously, our local host-based firewall does impact local users, but it’s also intended from outside access to our local resources. The firewall daemon is a zone-based firewall, we categorize our network interfaces, the services, the port numbers we’re going to use into those zones to make it easy to kind of centralize all those resources.
Obviously, Firewalld will kick in for local connections and also outside connections. It also works hand-in-hand with SELinux. Firewalld obviously recognizes standard ports, those ports are either open or closed. SELinux also has some port-based information in there. My red-blue is kind of, once again, I’m just kind of looking at it from an outside perspective, local perspective, obviously, Firewalld will kick in for local users, but its primary function is for outside network-based access.
That obviously leads us into Access Control List. If we think about it, UGO Permissions only recognize users and groups there are, in many ways, local to the system. Yeah, you can get into a whole LDAP discussion in having centralized authentication, bear with me here, we’re looking at it from a Linux+ perspective.
UGO is really dependent upon the local users and groups of the system. What if I want to share a resource with somebody without necessarily creating an account for them? There’s got to be an additional mechanism that will allow that person to have access to that resource. That’s where the Access Control List come into play. Obviously, they kick in based upon IP address, based upon hostname, based upon port, but they do give us the ability to grant the standard read, write and execute permissions to users who aren’t necessarily local to the system.
Really, what we’ve kind of described here is it’s not a Linux+ security pyramid, so to speak, it’s more or less a Linux+ Lego brick series, regular bricks? Whatever you like to look at it as just know the fact that there are multiple security mechanisms in play that go above and beyond the standard permissions. The standard permissions are always going to kick in first, I use the analogy of them being like mom. If mom said no, it didn’t matter what dad said, but if mom says yes, I still have to check with dad.
Dad would be the Pluggable Authentication Modules, SELinux, Firewalld, the Firewall Daemon, and then, of course, our Access Control List. I hope this provides some valuable insight into the various security mechanisms in play. Once again, I just kind of take the news at Face Value and notice that there’s not a lot of Linux vulnerabilities out there, probably because we have multiple mechanisms working for us at all times. I appreciate you guys taking the time to watch the video, and I’ll talk to you soon. Take care.
