Tips for Taming SE Linux, Part Two

Last week we took the eagle's eye view of the principles behind SELinux. Today we'll dig a bit more deeply into SELinux policies, and then fire up Fedora 8 and see what SELinux looks like in practice. I recommend using the latest Fedora version as a 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 your application does, and how it interacts with everything else on a system. Dan Walsh, the lead SELinux developer for Red Hat, cheerily claims that "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.

For now we're going to make sure we understand SELinux fundamentals, and take a look at the nice Fedora tools for managing SELinux.

Policies: The SELinux Master Control Center

SELinux uses policies to enforce mandatory access controls (MAC), which you'll recall from part 1 foil zero-day attacks and privilege escalation, so 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 a lot.

Type enforcement means every subject on the system—that's right, all of them&mashhas 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.

Types are included in the security context. A security context has three elements: identity, role, and type identifiers, like this:

identity:role:type

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.