Security-Enhanced Linux Support

Thursday, September 22, 2011

Jamie Adams

4085079c6fe0be2fd371ddbac0c3e7db

Security-Enhanced Linux (SELinux) is an enhancement to the standard Linux kernel that provides fine-grained security by employing Mandatory Access Control (MAC) rules.

The aim of the Targeted policy is to provide additional security to some of the more commonly used daemons such as httpd, dhcpd, mailman, named, portmap, nscd, ntpd, portmap, mysqld, postgres, squid, syslogd, winbind, and ypbind by employing MAC rules.

For example, the Apache Web Server (httpd) daemon executes in its own domain httpd_t. Other daemons on the system which do not have policy written specifically for them run in the domain unconfined_t.

Daemons and system processes running in the unconfined_t domain only use the standard Linux Discretionary Access Control (DAC) method of access control. In SELinux, access is granted to processes on a per-domain basis; each domain has a set of operations it may perform on each type of file, directory, or other resource.

For security reasons, we preferred not to execute in the unconfined_t domain. Therefore, a specific policy module was written to augment the Targeted policy, which separated our Console, Dispatcher, and Core Engine components into their own domains.

Processes and files are labeled with an SELinux Context that contains additional information, such as an SELinux user, role, type, and, optionally, a security level. When running SELinux, all of this information is used to make access control decisions.

In Red Hat Enterprise Linux, SELinux provides a combination of Role-Based Access Control (RBAC), Type Enforcement (TE), and, optionally, Multi-Level Security (MLS).

/uploads/remoteimg/457cb56f3f05e3c838f5ed98ee9fe1c6.jpg

(Click image to enlarge)

The above image is the output from the ls(1) command using the -Z argument , which displays the SELinux Context assigned to a file object.

In previous releases of our tool, SELinux was not supported because the SELinux Context on file system objects could be destroyed and could only be restored by relabeling the object. Each file system object is referenced by its information node (inode) and the SELinux context is stored as an extended attribute.

Some of our modules created new files or worked with temporary copies of configuration files - then subsequently copied it to their final location. In these situations, a new information node was assigned. Several modifications to our Core Engine and associated modules were made to restore the SELinux context on such file system objects.

The goal of MLS policy is to allow a Linux operating system to get EAL4+/LSPP certification. In developing this policy, the fourth field of the security context, the security or sensitivity level has been turned on - this facilitates the handling of labeled files.

Furthermore, the MLS policy contains rules that not only govern what security types are able to do, but also what they can do when running at a particular security level. In MLS there are two components of the Security Level, the sensitivity level, which can go from s0-s15, and the capabilities, which can go from c0-c255.

The Multi Category System (MCS) policy was also added to the Targeted and Strict policies, which confines the sensitivity level to s0 but permits user defined capabilities.

We are also watching the National Security Agency's (NSA) Certifiable Linux Integration Platform (CLIP) project. This project defines a specific configuration of SELinux designed to provide the foundation for hosting secure applications.

Cross-posted from Security Blanket Technical Blog

Possibly Related Articles:
19708
Operating Systems
Information Security
Operating Systems Linux Network Security Mandatory Access Control Daemon SELinux
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.