The purpose of this article is to cover basic concepts and operations of administering SE Linux on an RHEL or Fedora system. This was penned to make an intro level HOWTO for getting started with SE Linux. My friend has already given an intro for this topic and I am just covering more on administering policies.

Many of us have the feeling that SELinux is too complex and forces too many changes on fundamental Linux concepts. This article covers the more basic aspects of SE Linux, and it covers topics like :

* How to use all the administrative commands that relate to SE Linux

* Difference between targeted and strict policies

* Some troubleshooting tools, that come in handy.

So I hope after going through this article, you will think of looking at SELinux as a solution rather than a problem. Yes, I have seen many forums posts that suggests disabling SELinux as a ready-made fix. Believe me, SELinux is there for a reason, and the fix for the problem probably lies in effective policy administration.

History

SELinux was developed by United States National Security Agency, NSA as a research project. Traditional linux leaves access control to the ‘system user’. User decides who can access their files, based on group membership. With the ACL option turned on in the file system, user can fine grain this control.

With SELinux, a concept called Mandatory Access Control (MAC) is introduced. We let the Security Administrator decide who can do what to which files. Users are put in domains and even if a user wants to share a file with another user, this will fail unless they are put in same domain. A Security administrator can decide that normal users cannot see certain files. If a user account is compromised the attacker cannot access these files. Even root account is under this.

Want to know more about MAC and DAC comparison? Refer to SELinux: For A Secure Web Space.

Architecture

In the SELinux environment, each system process(subjects) lives in a domain. Domain is an isolated sandbox kind of an environment, that defines the capabilities of that subject(process). Capabilities like say the files that a process can access.

Every object(files, directories, network-sockets) and every subject(process) has a security context. This security context has three attributes:

* User Identity

* Role

* Type
Typically the security context is displayed in the following format.

user_identity:role:type:sensitivity:category

Security Policy and Context Explained

A Security policy is a set of rules that guide the SELinux engine. Security policy controls what SELinux identity, a process(subject) is assigned, when it starts. The identity determines which roles are accessible to a particular process. Roles are used to determine which domains the process can switch to.
We will be focusing on type based enforcements, rather than role based models, as that is what is generally used by an administrator.
As mentioned earlier, three SELinux security attributes user, role and type, together make up the security context.
user_identity:role:type:sensitivity:category
User identities usually end in ‘_u’. eg: system_u
Roles are described with an ‘ _r’. eg: object_u
Processes(subjects) are executed in “domains”. Resources(objects) related to the process live in protected domain which are named as ‘types’. Normally subjects and objects which are associated with a domain or a type usually end with an ‘_t’. eg: httpd_exec_t (process/domain) or httpd_t (file/type).
Processes relate to domains, and objects(say files) relate to types. And both these are represented in a context with an “_t”.
More on Policy administration, and troubleshooting to follow…

About the Author :

Jimmy Works as Senior Software Engineer in Bobcares. He joined Bobcares back in Jan 2007. During his free time, he watches movies, and enjoys reading.

Co-Authored by Sankar.H