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.
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.