SELinux tutorial: Introduction to Linux kernel security

SELinux may seem too complex for some administrators who instead disable the useful Linux kernel security tool. Learn how SELinux works, including how subjects and objects work and security policy settings.

This Content Component encountered an error

Although Security-enhanced Linux (SELinux) has been available in the Linux kernel for almost ten years, it has remained largely unexplored by administrators due to its assumed complexity. Many Linux administrators just disable SELinux on their Linux servers to avoid configuring around it when setting up applications.But, SELinux is a very useful tool for Linux security. Learn how it works and how you can manage SELinux policy and access...

control to protect your Linux servers. 

SELinux is an implementation of a mandatory access control (MAC) security model in Linux operating system (OS). This mechanism resides inside the Linux kernel and checks for allowed operations after standard Linux discretionary access controls (DAC) are enabled

Understanding DAC and MAC Linux security models

As SELinux is based on the concept of MAC, it is very important to understand shortfalls of DAC (the default Linux security model) and advantages of MAC over DAC.

Under MAC, administrators control all interactions of software on the system. The concept of least privilege is used, and by default applications and users have no rights, as all rights must be granted by an administrator as part of the system’s security policy. Under DAC, files are owned by a user and that user has full control over them. An attacker who penetrates an account can do anything with the files owned by that user. For example, a hacker gaining access to a FTP server will have full control over all files owned by the FTP server account. Worse, if an application runs under the context of the root user (which is common for services like Web and FTP), an attacker will have full control over the entire system.

MAC provides each application with a virtual sandbox that only allows the application to perform the tasks it is designed for and are explicitly allowed in the security policy. For example, the Web server may only be able to read Web published files and serve them on a specified network port. An attacker penetrating it will not be able to perform any activities not expressly permitted by the security policy, even if the process is running as the root user.

Standard Unix permissions will still be present on the system, and will be consulted before the SELinux policy when access attempts are made. If the standard permissions would deny access, access is simply denied and SELinux is not involved. However if the standard file permissions would allow access, the SELinux policy is consulted and access is either allowed or denied based on the security contexts of the source process and the targeted object.

How SELinux defines subjects and objects

There are two important concepts, subjects and objects, in MAC's security context. A MAC (or non-discretionary access control) framework allows you to define permissions for how all processes, called subjects, interact with other parts of the system such as files, devices, sockets, ports, and other processes -- objects. This is done through an administratively-defined security policy over all processes and objects. These processes and objects are controlled through the kernel, and security decisions are made on all available information rather than just user identity. With this model, a process can be granted just the permissions it needs to be functional. This follows the principle of least privilege, which contrasts with the full privilege concept of DAC.

Under MAC, for example, users who have exposed their data using "chmod" are protected by the fact that their data is only associated with user home directories, and confined processes cannot touch those files without permission and purpose written into the policy.

SELinux security policies: Strict and targeted

SELinux follows the model of least-privilege. By default, everything is denied and then a policy is written that gives each element of the system (a service, program, user, process) only the access required to perform specified function. If a service, program or user tries to access or modify a file or resource that is not necessary for it to function then access is denied and the action is logged. Because SELinux is implemented within the kernel, individual applications do not need to be especially written or modified to work with SELinux. If SELinux blocks an action, this appears as just a normal "access denied" type error to the application.

The flow of SELinux with default targeted policy can be depicted as following logical block diagram:


Click on image for larger version

One of the most important concepts is SELinux policy. The model of least-privilege best describes the “strict” policy. SELinux allows different policies and the default policy in CentOS 5 and RHEL is the “targeted” policy that targets and confines key system processes. In RHEL, over 200 targets exist (including httpd, named, dhcpd, mysqld). Everything else on the system runs in an unconfined domain and is unaffected by SELinux. The goal is for every process that is installed and running at boot by default to be running in a confined domain. The targeted policy is designed to protect as many key processes as possible without adversely affecting the end user experience and most users should be totally unaware that SELinux is even running.

Another important concept is SELinux access control. There are three forms of access control, which are type enforcement (TE), role-based access control (RBAC) and multi-level security (MLS). Among these, TE is primary mechanism of access control in targeted policy.

Setting up the SELinux security context

It is very important to understand, that all processes and files in SELinux model posseses an SELinux security context.This security context can easily be displayed by using "-Z" flag as shown below:


Click on image for larger version

Most of the SELinux troubleshooting revolves around security contexts of objects. These security contexts are in format of user:role:type:mls. Field  "mls" is always hidden (as being default in targeted policy), so for example for hello.pl file, root is user, object_r is the role and type is httpd_sys_content_t. Within the default targeted policy, type is the important field used to implement TE, shown above. 

Similarly you can list the security context of all processes running in Linux using same "-Z" flag with ps command, for example

 #ps -efZ | grep mail
 system_u:system_r:sendmail_t    root      2661     1  0 12:30 ?        00:00:00 sendmail: accepting connections
 system_u:system_r:sendmail_t    smmsp     2670     1  0 12:30 ?        00:00:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue

The above output shows that Sendmail processes on our Linux server are running under "Sendmail_t" type domain.

Editor's note: Two upcoming tips will delve into SELinux using Boolean conditions in RHEL, securing Web servers using SELinux, and SELinux commands.

ABOUT THE AUTHOR: Khurram Shiraz is Technical Consultant at GBM Kuwait. He has worked with high availability technologies and monitoring products such as HACMP, RHEL Clusters and ITM,and implemented IBM & EMC SAN/ NAS Storage. He also designs and implements high availability, parallel computing and DR solutions based on IBM pSeries, Linux and Windows infrastructure.

More from the SELinux tutorial series:

This was first published in January 2011

Dig deeper on Linux security tools

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchDataCenter

SearchServerVirtualization

SearchCloudComputing

SearchEnterpriseDesktop

Close