Demystifying SELinux on Kernel 2.6

If you’re looking for a way to control or restrict access to your Linux-based applications, you might want to look at SELinux. This extension has been around since Linux kernel 2.6 and can help you with your access issues.

Before we begin, first we need to understand what kind of access control we’re talking about, and then we can easily comprehend how "mandatory access control" (MAC) tries to accomplish our aims. The operating system has the ability to examine the course of an action that an "initiator" wants to perform on a so-called "target." In its simplest form, imagine a process wanting to do something (i.e.; open, write, modify) with a file.

In the case above, the initiator is the process, while the target or the object is the file. The mechanism needs to be globalized and extended to directories, memory segments, and even TCP/UDP ports, not to mention lots of other objects. The same is true of the initiators; they can be not just processes but also threads and so forth. Let’s keep things simple.

The operating system is responsible for maintaining the overall security of the system from the software level. It’s like a Big Brother, watching everything from the "top" with a global understanding of virtually anything that happens. Each operation ought to be examined and matched with a set of rules and authorizations. These policies in our case can be MAC or DAC-mandatory or discretionary access control.

Please note that in this article, the presence of the MAC abbreviation stands for Mandatory Access Control and has nothing to do with the unique identifier that is given to network devices, commonly known as the "MAC address," which is short for media access control address. This can create confusion, but this is a software article focusing on the access controls of the Linux operating system.

All right now, we’re slowly escalating and getting to the point of things. There’s still much to be demystified and explained before the big picture comes together. On the next page we will see how MAC approaches "access controls" in comparison with the old-fashioned DAC. Then we’ll cover how MAC could be implemented in Linux. Turn the page!

{mospagebreak title=Basics of SELinux}

The old-fashioned way of setting permissions to files, for example, is the DAC way that people commonly recognize as the "rwx" method (read – write – execute). You know, for example, that setting permissions with 777 meant rwx for everyone; you also know how to calculate those bits, and all that. There is no point getting into this; rather, I’ll just present MAC in comparison with this solution.

Using the old mechanism, we could easily change the permissions, if need be. MAC takes a totally different approach. The mandatory access control policies cannot be overridden, neither intentionally nor accidentally. These policies are set by system administrators and then enforced throughout the entire organization.

As you can imagine, professionals recognized that there was a need for a different approach that somehow limited the access of users to alter these configurations. They needed to be globalized and enforced throughout an entire organization. As such, the solution become quite clear-policies. They not only were transparent to users and applications, they also removed the power of root, and offered a fine-grained control over the kernel’s services. And the system administrators could specify these policies.

Implementing the above mechanism without changing the architecture of how Linux operating systems work was tough. The complexity could not be increased; still, major changes were required. Finally, the LSM "approach" was taken. This stands for Linux Security Modules. It is an extension that supports various numbers of security models in the official kernel (since 2.6 mainstream).

Without getting really technical, LSM was the solution that required the least amount of changes to the Linux kernel, due to the addition of hooks. These so-called hooks are used for access control, since they are present (and can be used) at every user-level system call of the kernel. So before accessing inodes, hooks will be there.

To fully implement and build on top of LSM, SELinux developers realized that they need a file system that allows labeling-extended attributes. These associated attributes are stored with the inodes. Security contexts are associated with other objects as well. Basically, an operating system would need the new patch to support those hooks to manipulate the access controls, the LSM module, and the MAC framework.

And this is where we finally introduce SELinux, an implementation of a mandatory access control framework based on the techniques presented above. The way it works is totally transparent to users and applications. There are two kinds of policy types.

The first type is Strict. Under this type, you can set allow-only rules, since the system by default denies everything. The second is Targeted; in this case, you use deny rules, since it allows everything by default. The system runs the processes and daemons for which there is no rule specified in a way that is akin to not running SELinux at all.

By now you should have a slight idea of how SELinux works and what it does. On the next page we will further examine its functionalities and behavior. Stick with us.

{mospagebreak title=More About SELinux}

A few technical terms need to be introduced to ease things later on. A while ago we mentioned that security labels or so-called contexts are associated with initiators and targets. File_context is the security label associated with files (objects) and domain when we talk about processes. The bottom line is that these contexts are located within inodes. The context is built up, usually, by four components. Let’s see which ones these are.

The first component is the one specifying which group the roles are part of. These can be system_u, user_u, and root. Processes not executed by users (i.e. that are run during the boot-up process) are commonly associated with system_u, while user_u is the default user for logged-in users, and the root is self-explanatory.

The second component stands for the role field. This component is negligible in the case of files (it’s always object_r but irrelevant) since they are specifically useful on domains (i.e. processes). By convention, these end with "_r" just as the users that we talked about in the paragraph above got the suffix "_u". A few role examples include sysadm_r, staff_r, etc.

The third component is the type. It ends with "_t." This field represents the basis for the type enforcement functionality of SELinux. An example of a policy that uses this kind of type enforcement is specifying which type of initiators have access to which kind of object types. The last component is the MLS component, and on most targeted or strict machines, it’s"s0" by default, which can also be "". It’s quite irrelevant to us.

Ever since the Linux Security Module (LSM) became integrated into the kernel as a general-purpose model, SELinux could be implemented to work on top of it, without being required to be shipped as a set of patches and extensions of its own. The appearance of LSM brought with it lots of possibilities for enhancement, since it enabled stacking of security models. This way it helped along Linux security’s modularity.

Aside from the previously-discussed mandatory access control solution, SELinux also makes it possible to work with role-based access controls (RBACs). Roles differ from groups in various shapes. For example, a role stands for users, but also for permissions that specific users are able to perform. In the case of groups, programs are given the least privileges to perform their own tasks, but just that. This is based on MAC.

Understanding and finding your way around SELinux policies requires research. We recommend that you look through the man pages of policies and check a few of the SELinux-specific commands for your distribution. You need to monitor and understand access vector cache (AVC) messages. These can be found inside /var/log/messages or /var/log/audit.log. These are verbosely logged, and you can find out what happens inside.

There are really useful auditing tools that help you with understanding AVC log messages. Such tools are audit2allow and audit2why. The first generates allow-rules based on the logged denied operations, while the second answers the "why" question by analyzing the denied audit messages and transcribing them into a descriptive format.

As a final rule of thumb, get familiar with the "Z" kind of Linux commands, such as the "ls -lZ" or the "id -Z", and many others. Managing file labels is also another concept we’d advise looking into. On another note, applications might fail without any AVC message traces. Policies can also be created with booleans (if/then/else).

{mospagebreak title=Final Thoughts}

This article merely demystified what SELinux is. Gaining expertise with it requires research and time. More than this is beyond the scope of this overview. By now you should have understood what it does and how it came to life. Should you want further information, you will know what to search for and where.

Lots of people don’t know what SELinux is despite the fact that they might be familiar with using functions and features which would not be possible without this extension. Others might have heard of SELinux, but they only know it’s some U.S. DoD specific project that is "oh so" secretly kept. The presence of SELinux ever since kernel 2.6 is one of those topics that needs a bit of light shed on it.

SELinux is a proven solution for restricting applications, but it would be silly to think it’s the only approach that was designed and implemented. Another solid alternative could be AppArmor. It takes a slightly easier approach than SELinux because it works with file paths rather than labels (it is not based on inode numbers). Originally maintained by Novell, it has been taken over by openSuse devs, and is now licensed on GNU GPL.

In a future article we are going to overview AppArmor and compare it with the characteristics of SELinux presented in this article. Both security solutions are rather fantastic; they’ve been proven to be reliable over the years, so it’s especially important to be familiar with both. In that way we’ll be qualified to take an educated guess for when to use which, and be able to handle both of them seamlessly. 

In closing, I’d like to invite you to join our community of technology professionals experienced in all areas of IT&C starting from software and hardware up to consumer electronics at Dev Hardware Forums. Also, be sure to check out the community of our sister site at Dev Shed Forums. We are friendly and we’ll do our best to help you.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye