SELinux - Users, Policies, Security Contexts, Roles

I introduced SELinux and it's generalized form in my previous blog post, and as promised wanted to touch base on more of the underlying functionality and setup of SELinux on standard 2.6 Kernels.

SELinux being that of a FLASK (Flux Advanced Security Kernel) implementation encompasses a wide array of MAC oriented policies, including but not limited to type enforcement, role-based access control and multilevel security, all of which were prototyped in the Fluke operating system.

First things first, recalling that a subject is typically a process or thread with its own set of security attributes and an object being that of typically constructs such as files, directories, TCP/UDP ports, shared memory segments also with its own set of security attributes, it's important to understand the association of three fundamental SELinux related attributes :

1. Users
2. Policies
3. Security Contexts

 Without regard for the order inwhich they are listed above, it's easier to understand by demonstration of the security contexts, just how each SELinux attribute interacts with one another.

Before exploring the details of security contexts, it's important to note that many users are unfamiliar with the GNU 'ls' formatting structure, when for example using the 'l' option (long listing) combined with 'a', ie:

Take note of the trailing bit !  The additional trailing bit, is to mark the presence of an additional access method on the object.  A space representing the opposite scenario.

A '+' represents an ACL (Access Control List) association with the object, a '.' represents SElinux.

Back to SELinux !
 

"SELinux adds the -Z switch to the shell commands ls, ps, and some others, allowing the security context of the files or process to be seen." (Wikipedia)

The above screen shot outlines the security contexts of .bash_history, as prescribed by SELinux.  The security context consists of four fields: user, role, type and level.  All fields are required, except for the level.

User Field 

• 'unconfined_u' in our example
• Conventionally all default SELinux Users end with a "_u" except for root.
• Consider this component a way of grouping 'roles'
• Three typical users seen on a system are : user_u/unconfined_u, system_u and root
• "user_u"/"unconfined_u" is the default SELinux User for a logged in user on a system
• "system_u" is the default User for processes started during the boot up process
• "root" is the SELinux user that you get when you login at the console as "root"
• SELinux user differs from a convential Linux user in that a SELinux user "attribute" is binded to your login, regardless of let's say issuing a 'su' command.  In easier to understand terms, take for example linux user 'infolock', with an SELinux user associated attributed of "unconfined_u" as shown above.  "infolock" issues 'su' , yet, is still labelled "unconfined_u" by SELinux, and still under the "restrictions" of the security policies set forth by SELinux related to unconfined_u User.   SELinux login, handles the mapping of SELinux related users and standard linux uids.   Issuing 'semange login -l' will display the correlation in SELinux Login.

• The first column denotes the typical linux uid and the second column being that of the SELinux user identity.  The last column is the MLS/MCS (Multi Level Security/Multi Category System) Range, discussed later in this post.
• To better understand the mapping of linux uids to SELinux user identities, execute the following command 'semanage user -l' which outputs the definitions of the SELinux user identities.

Role Field

• "This field is only really relevant on processes or domains. The role field on a file is always object_r, and really has no meaning other than as a place holder. On a process you would usually see a role like system_r or sysadm_r. Roles are used to group security types. So you can specify in policy which roles are able to execute which types. This is the basis of "Roles Based Access Control" (RBAC) in SELinux. RBAC is not really used in targeted policy, but becomes more important in Strict and MLS policy. MLS Policy also contains sysadm_r, staff_r, and secadm_r. Roles by convention end with a "_r". "(Fedora Project, wiki)
• Roles are predefined in SELinux policy
• SELinux Roles determine which process domains / object types can be accessed. All processes under SELinux run under a domain. A domain specifies what can be performed by processes while a type specifies who can access an object.

Type Field

• "The 3rd component of the security context is the Type component, for example /usr/sbin/httpd is labeled with a type of “httpd_exec_t".
  In my opinion this is the most important field in the SELinux security context. This is the heart of SELinux Type Enforcement. Most of the policy rules in SELinux revolve around what subject types have what access to which object types. By convention this component always ends in a "_t". "(Fedora, Wiki)
  

Level Field

• "The 4th component is the MLS, or Multilevel security, field which is not supported in RHEL4 or Fedora Core 4. It is first showing up with Fedora Core 5, although it has been in SELinux in the previous versions, it was never turned on.
  This component is used in all policies shipped with Fedora Core 5. On strict and targeted policies we refer to this as the MCS (Multi Category System) Field. Unfortunately this field can contain a ":". The syntax of this field can look something like s0-s15:c1,c2. But I will put off talking about this syntax until a later date. Most files by default are labeled s0, sometimes referred to as SystemLow. Fortunately SELinux provides a translation library (libsetrans) that replaces the codes in this field with a more human readable form. So something like s0:c1,c2 might be show up to the user as PatientRecord,CompanyConfidential. On a targeted or strict policy machine s0 translates to "", so almost all files will not even show the fourth field." (Fedora, Wiki)
   

Armed with your new understanding of SELinux and it's associated attributes (secutiy contexts, types, roles, levels and the likes) it's time to re-examine the commands we issued in the first blog post, to enable SELinux access to userdir apache settings.

Prior to executing the following commands :

#setsebool -P httpd_enable_homedirs 1
 &
#chcon -R -t httpd_sys_content_t ~user/public_html


We were still receiving 403 errors, when trying to access local documents via userdir directories.  So what have we done, through the execution of the two commands to change it ?

First !  setsebool ,

To change parts of the SELinux policy at runtime without having to reload a new policy, we manipulate the boolean values of specific daemons with respect to the SELinux policy.

"booleans - Policy booleans enable runtime customization of SELinux policy." (boolean(8))

in the 'setsebool' command above, we are using the option -P, which specifies that the value we are manipulating remain persistent across reboots. 

The boolean in this case is "httpd_enable_homedirs".   Allowing httpd to read home directories.  To determine what the current boolean settings are on your particular machine, provided you have SELinux installed and enforcing a policy run any of the following commands:

$getsebool -a
#semanage boolean -l
$getsebool httpd_enable_homedirs

The boolean value of 1 signifying 'on' and 0 signalling 'off'.

Next comes, chcon,

The chcon command changes the SELinux context for files. Keep in mind changes made with the chcon command do not survive a file system relabel, or the execution of the /sbin/restorecon command.  Essentially what we are doing here, is recursively (-R) changing the SELinux type (-t) association of all security contexts contained in '~user/public_html' to httpd_sys_content_t , which depending on the type of policy currently enforced, can be manipulated once again.

So there you have it, the truth about SELinux, how to properly configure Apache to work with USERDIRS and SELinux, and a bit of information related to the configuring of SELinux on the whole.

Hope it helped.

Expect more to come on the topic of SELinux.  Enjoyed writing this article.

~infolock