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

For your viewing pleasure.....

Go confidently in the direction of your dreams.Live the life you have imagined.

~infolock

Apache USERDIR Access rights via SELinux (Fedora Core 12)

Today I set up Apache on my Fedora Core 12 x86_64 machine. To avoid the read of the underlying logic behind SELinux, feel free to browse this blogpost, noting only lines editted in bold.

The following article will detail the process of establishing your userdir setup on Fedora, without disabling SELinux.  Essentially rendering /~username/public_html directories available for localhost web development.  Good luck!

Initially, I ran:
$rpm -q httpd
to determine wether or not I had such services bundled with my installation.

The result:
httpd-2.2.15-1.fc12.2.x86_64

Perfect !  Time to set up permissions !

It's a hassle having to manage to /var/www/html as the directory default, when you don't want to have to develop via 'root'  so here are the steps I followed to setup USERDIR settings with special privileges for SELinux.

SELinux, as some of you may not know stands for 'Security-Enhanced Linux' and is a "security architecture integrated into the 2.6.x kernel using the Linux Security Modules (LSM)." ( Red Hat Enterprise Linux 5 Deployment Guide, ref-G)  It's development was a joint effort between the National Security Agency of the United States and Redhat.

To determine whether or not SELinux is enabled on your system, issue the following command:
$cat /etc/selinux/config

The SELINUX variable may be set to one of three options ('modes'):

1. disabled
2. permissive
3. enforcing

As described below:


disabled

• completely disabling the SELinux kernel and application code

permissive

• enabling the SELinux code, with minimal restriction on access, however calls / requests are audited.

enforcing

• enabling the SELinux code, enforcing access denials as well as audits.

You may have noticed another variable contained in the config file :

SELINUXTYPE

This post will not dive into the details of such configuration options with respect to SELinux, but I will touch base on the issue at a later date.  For more information regarding the variable SELINUXTYPE's configuration, reference either the man pages or search for SELinux policy types.

Back to the basics !

"Security-Enhanced Linux is a Flux Advanced Security Kernel (FLASK) implementation integrated in some versions of the Linux kernel with a number of utilities designed to demonstrate the value of mandatory access controls to the Linux community and how such controls could be added to Linux. Such a kernel contains architectural components prototyped in the Fluke operating system. These provide general support for enforcing many kinds of mandatory access control policies, including those based on the concepts of type enforcement, role-based access control, and multilevel security. FLASK, in turn, was based on DTOS, a Mach-derived Distributed Trusted Operating System, as well as Trusted Mach, a research project from Trusted Information Systems that was influential in the design and implementation of DTOS." (Wikipedia)

To better understand the technology behind SELinux, one must first grasp the concepts of DAC (Discretionary Access Control).  The typical access layer found on linux distributions.

Essentially DAC "is a kind of access control defined by the Trusted Computer System Evaluation Criteria^[1] "as a means of restricting access to objects based on the identity of subjects and/or groups to which they belong.". (Wikipedia)

To further help you understand, the following is a result of :
$ ls -al /var/www

The object 'usage' has the following permissions:
drwx:r-x:r-x

• The 'd' specifying 'directory.

• The following three characters (rwx) representing the access privileges for the owner, in this case 'webalizer'.  Read, Write, and eXecute respectively. 

• Following that, we see, (r-x).  These permissions correspond to the assigned group of which the object is associated.  In this case 'root'.  We see that such a group, has the following permissions:  Read and eXecute.

• The three trailing permission bits are associated with 'others' but can be thought of as 'everyone' , whom are granted both Read and eXecute permissions.  

"The term DAC is commonly used in contexts that assume that every object has an owner that controls the permissions to access the object, probably because many systems do implement DAC using the concept of an owner. But the TCSEC definition does not say anything about owners, so technically an access control system doesn't have to have a concept of owner to meet the TCSEC definition of DAC.
Users (owners) have under this DAC implementation the ability to make policy decisions and/or assign security attributes. A straightforward example is the traditional Unix permissions with its system of users, groups and read-write-execute permissions for objects (ie. files and directories)." (Wikipedia)

So that is DAC !  Now you know, but just when you thought you had that digested, there is more.

Bring in MAC !

No, not Macintosh.  Mandatory Access Control of course !

Before I begin with the formal introductions, it may be best to familiarize yourself with the following definitions.  As you will soon see, they tie in nicely when deciphering the logic behind access control.


subject a.k.a initiator

• usually a process or thread with its own set of security attributes

object a.k.a target

• typically constructs such as files, directories, TCP/UDP ports, shared memory segments also with its own set of security attributes

Onto the introductions ...

 "Whenever a subject attempts to access an object, an authorization rule enforced by the operating system kernel examines these security attributes and decides whether the access can take place. Any operation by any subject on any object will be tested against the set of authorization rules (aka policy) to determine if the operation is allowed." (Wikipedia)

In contrast to DAC which allows users to manage authorization rules and or assign security attributes, MAC is governed by a "central" security policy administrator, who controls the implementation of organization-wide security policies, of which can not be manipulated by users. 

It would seem at this point from analysis, that the two are somewhat polar opposites of one another.  Why on earth would you need to know about MAC if a typical distribution delivers DAC!  Well, SELinux, the overall focus of this blog post builds an access layer on top of DAC, guess it's classification if you want to call it that.  That's right MAC.


"On the other hand, systems can be said to implement both MAC and DAC simultaneously, where DAC refers to one category of access controls that subjects can transfer among each other, and MAC refers to a second category of access controls that imposes constraints upon the first." (Wikipedia)

"From a puristic perspective, SELinux provides a hybrid of concepts and capabilities drawn from mandatory access controls, mandatory integrity controls, role-based access control (RBAC), and type enforcement architecture. Third-party tools enable one to build a variety of security policies." (Wikipedia)


A generalized breakdown of the SELinux "architecture" is as follows, when investigating the process of object access requests:

1. Subject attempts to access object.
2. Subject must first pass DAC authentication.
3. Upon clearance of DAC, MAC steps in.
4. The subject sends an action request to the SELinux Security Server, a.k.a. the policy enforcement server.
5. The policy enforcement server references the SELinux Policy Database via AVC (Access Vector Cache) or Security Context Matrix to verify policy permissions on the requested object.
6. The server will either grant permission to the object based on policy or deny and log the attempt.

Now that most of the formal introductions with respect to SELinux, FLASK, MAC and DAC are out of the way, it's time to get back to the goal of the topic!

Having identified SELinux was setup and enforcing the access control policies in co ordinance with the kernel, it was no longer a mystery after having configured my httpd.conf file like so:

#vim /etc/httpd/conf/httpd.conf

Take note of the commented text apparent in the clause about enabling UserDir permissions!

The following commands, were then to follow:

#chmod 711 /home/user

• Don't forget to replace 'user' with the name of the account you would like to develop on !

Create the public_html directory in your /home/user directory.

$mkdir public_html

Set the permissions !

$chmod 755 public_html

For those with SELinux disabled, this would be all that would be required.  You should be able to successfully navigate your browse to "localhost/~user/" and pull the default (index.html file) from the directory, provided you have created it !

But for those of us with SELinux enabled and enforcing the policy rules, a few more steps remain!


#setsebool -P httpd_enable_homedirs 1


#chcon -R -t httpd_sys_content_t ~user/public_html

• Don't forget to replace 'user' with the account you used in the above steps!

A rather gentle restart of the services via :

#service httpd restart

And you should be on your way to developing local sites via your userdir!

Now that's great and all, but after having read a short novel about the logic behind SELinux, I have failed to answer a question on many of your minds.  That being, what exactly did the two commands above, have to do with configuring SELinux ?

Check out my next blog post, where I'll detail the users, policies and security contexts of SELinux, which will help clarify just what permission bits were set, and help you build a solid foundation of SELinux on the whole.

Hope it helped!  Keep the information free !



~infolock