Previously, we took the eagle’s eye view of the
principles behind SELinux. Now, we’ll dig deeper into SELinux policies, and then fire up Fedora 8 and see what SELinux looks like in practice.
Using Fedora’s SELinux implementation as a guide, learn how MAC security policies work in practice.
I recommend using the latest Fedora version as an SELinux training tool because Fedora has the most mature implementation and userspace tools. Red Hat Enterprise Linux and CentOS, the leading Red Hat clone, have similar SELinux setups to Fedora. Gentoo also has a nice SELinux implementation. I don’t recommend starting from scratch. Start with a working setup, and then plan to spend considerable time learning your way around it, because it is a big complex beast.
It’s not that SELinux itself is so complex; it’s the scale of it. SELinux wants to touch every file and process on your system. Fedora, RHEL, and Gentoo come with prefab policies, and this is a good thing because writing SELinux policies is a large undertaking. To write a good policy you need a thorough understanding of what an application does and how it interacts with everything else on a system. Dan Walsh, the lead SELinux developer for Red Hat, cheerily claims “customizing your system’s protection by creating new policy modules is easier than ever!” Which is very much a relative statement, akin to “Thanks to modern high-tech gear, visiting the Moon is easier than ever!” But it’s not impossible, and Mr. Walsh is encouraging and helpful, having written reams of SELinux documentation.
To ensure an understanding of SELinux fundamentals, let’s take a look at the Fedora tools available for managing SELinux.
Policies: The SELinux Master Control Center
Unsure About an Acronym or Term?
SELinux uses policies to enforce mandatory access controls (MAC), which you’ll recall from our previous discussion of zero-day attacks and privilege escalation. Let’s see what goes into making a policy.
SELinux calls users, processes and programs subjects. Objects are files, devices, sockets, ports and sometimes other processes. Subjects can be thought of as processes, and objects are the targets of a process operation.
SELinux uses a kind of role-based access control (RBAC) combined with type enforcement. Type enforcement enforces policy rules based on the types of processes and objects, which it tracks in a giant table. Types and domains are the same thing; you’ll see both terms often.
Type enforcement means every subject on the system — that’s right, all of them — has to have a type assigned to it. Types are stored in security contexts in the extended attributes (xattrs) of the files. This means they are stored in the inodes, which means that no matter how many weirdo soft or hard links are attached to your file, the security context is inescapable, and will not be fooled by silly evasions such as renaming the files or creating crafty softlinks.
Read More About SELinux
Types are included in the security context. A security context has three elements: identity, role, and type identifiers, like this:
You can see these with the Z option to the ls command:
$ ls -alZ /bin/ping -rwsr-xr-x root root system_u:object_r:ping_exec_t:s0 /bin/ping
What do these things mean? system_u is a system user. Files on disk do not have roles, so they are always object_r. ping_exec_t is the type for the ping command. You will also see documentation that calls this the domain.
This article was originally published on Enterprise Networking Planet.