Understanding SELinux

From the 6th century BC, around the time the Art of War was written by Sun Tzu, till today, the basic tenets of warfare attack (offence) and security (defence) remain the same. What has changed significantly from those days is the terrain. It has evolved from land and sea, to air and into cyberspace.

Securing cyberspace, especially in this connected world of the Internet, is of prime concern to governments, organisations and individuals. In a knowledge economy, the real wealth is in information and the bits of data that provide it.

Securing access to that data is of fundamental importance to the very existence of an organisation. CIOs and IT managers worldwide therefore look at security as one of their main areas of concern. IT security is a vast subject and covers many areas—the foremost being network security (firewalls), data security (encryption, backup, etc), computing security (restricting physical access, patching OS vulnerabilities, etc) and application security. Much attention has been paid to network security, data security and computing security, and thus there are a lot of products in the market competing with each other providing security solutions in these spaces.

But simply buying and implementing the security products in not enough. As Bruce Schneier states in his remarkable book, Secrets and Lies: Digital Security in a Networked World, the two fundamental principles about digital security are:

• Security is a chain; it’s only as secure as the weakest link.
• Security is a process, not a product.

The application is a very important link in the IT security chain. It is the application that the end-user consumes and it is the application interface that is exposed to all users (even those without proper login credentials). These applications control the use of resources granted to them by the OS—memory, storage, networks, etc. Most applications are complex and run into tens of thousands of lines of code and can contain innumerable vulnerabilities.

Moreover, typically, multiple applications are executed on the same operating system instance. To give a simple example, a mail server running SMTP/POP/IMAP will, in all probability, also be running a Web server. The Web server interface could be used for configuration or even for Web mail purposes.

Vulnerabilities in one application could bring down the entire system affecting other services and processes, or worse, lead an attacker to a storehouse of confidential information.

Why SELinux?

Application software will have its flaws and bugs, and will remain like that in the near future, depending on the nature of the application and the constraints/awareness of the developers.

If multiple applications running on the same OS have to be secured, the OS has to play a crucial role in defining the confines of these applications. Security can only be achieved with better underlying operating system security that can isolate applications and files used by each, thus protecting the integrity of the entire system.

In most organisations that have implemented some form of security and have a security policy in place, the weakest link in the security chain are the systems administrators. They generally have access to most files in the system and can—by accident or design—perform operations on confidential files. Confidentiality of data in modern systems is another pressing requirement.

The NSA (National Security Agency) of the US, which originally developed SELinux, states: “The Security-enhanced Linux’s new features are designed to enforce the separation of information, based on confidentiality and integrity requirements. They are designed for preventing processes from reading data and programs, tampering with data and programs, bypassing application security mechanisms, executing untrustworthy programs, or interfering with other processes in violation of the systems security policy. They also help to confine the potential damage that can be caused by malicious or flawed programs. They should also be useful for enabling a single system to be used by users with differing security authorisations to access multiple kinds of information with differing security requirements without compromising those security requirements.”

In other words, SELinux does implement some kind of Access Control Mechanism to achieve the above. Traditional UNIX-like operating systems have had an Access Control Mechanism that has remained, and still remains, one of the strongest security features of this family of operating systems.

We are all aware of the ‘rwx’ bits set on files and folders along with some special permissions. These permissions, along with user identity (UID) and group identity (GID), form the basis of traditional access control. This access control prevents unauthorised access to files and processes. chroot jails further confine filesystem access to a running process.

Is there a flaw in this age-old time-tested Access Control Mechanism? If no, what is the need for SELinux?

The inherent flaw in the traditional permissions model is that of DISCRETION. The owner of a particular file, for example, can change the permissions of an object, at will. Just imagine the following scenario:/etc/passwd, the file that contains the user database, has default permissions of 644 and the file is owned by the root user, who—by accident or design—assigns it 666 permissions (global read and write). Any user could write into the user database, thus changing UIDs, home directories, etc. Imagine the security breach if the root user were to do such a thing.

The traditional Access Control Mechanism of permissions on files and processes is thus discretionary—it can be changed at the discretion of the owner and is often termed as Discretionary Access Control (DAC). Herein lies an inherent security flaw.

By contrast, SELinux implements Mandatory Access Control (MAC), where access control decisions are not at the discretion of individual users or even systems administrators.

Understanding MAC

Mandatory Access Control (MAC) ensures that the security policy of an organisation is adhered to. The various ‘actors’ in
any security policy can broadly be classified as:

• Subjects
• Objects

Subjects perform certain operations on objects and the security policy specifies which of these operations are allowed or disallowed through Mandatory Access Control. In an operating system:

• Subjects are typically processes or threads.
• Objects are typically files, directories, TCP/UDP ports, shared memory segments, network interfaces, etc.

When an application process or thread tries to access objects that are disallowed in the security policy, an ACCESS DENIAL occurs, thus providing a layer of security between applications. Each application can be understood to be running in its domain, and subjects can typically access objects or perform operations within this domain, thereby confining the application within the boundaries of its ‘domain’.

A new process/thread, on execution, might create its own domain through something referred to as domain transition. We will come to this in the later part of this series.

To identify subjects and objects and to determine what access is allowed to whom, SELinux implements a MAC mechanism called Type Enforcement. This enables a granular control of the access mechanism over the operating system.

Type Enforcement and Security Contexts

Under Type Enforcement, certain attributes are applied to all objects and subjects. These attributes are termed as Security Contexts. Each process and file/directory/port on the system is assigned a Security Context based on which the Type Enforcement policy allows/disallows access.

Security Contexts are stored in Extended Attributes (xattrs) on an ext2/ext3 filesystem. A typical SELinux security context is of the form: User Identity:Role:Type/Domain.

In multi-layer security and multi-category systems, two more attributes—sensitivity and category—are added. We will come to these later in the series.

Roles and users in the security context are present to support RBAC (Role-Based Access Control) features in SELinux. RBAC is to enable user privileges within the SELinux system. This too will be discussed later.

In this introductory article, our focus will be on SELinux Type Enforcement to give you a feel of SELinux, and thus we will primarily highlight the third attribute of the Security Context—Type/Domain.

Introduction to SELinux policies

The SELinux Type Enforcement Policy is based on rules that apply on Security Contexts. Processes running with a certain Security Context are either allowed or disallowed to perform operations (access permissions—read/write/getattribute/setattribute, etc) on objects with certain Security Contexts.

The total compilation of these rules is called a SELinux policy. Red Hat Enterprise Linux comes with two standard policies—Targeted and Strict. To briefly summarise the above:

• All processes (subjects), files, TCP/UDP ports, etc, (objects) are assigned a security context.
• Rules are created that allow/disallow access type (read/write, etc) by subjects to objects based on Security Contexts of the subject and that of the object.
• The set of these rules creates a policy. Currently, we are discussing Type Enforcement Policies.
• This policy is applied mandatorily to the system and cannot be overridden by users and even system administrators.
• Mandatory Access Control through Type Enforcement Policies enables SELinux fine-grained control over the operating system and any applications that might be running on top of it—adding an extra defence layer.

Enabling SELinux

Before beginning to explore SElinux, we need to enable it in the system. I use Red Hat Enterprise Linux 5 on my desktop, though the concepts and most of the commands would be the same on other flavours as well.

First, check whether SELinux is enabled on your system—as root, run the following command:

[root@vbg ~]# sestatus

If your output is:

SELinux status:              disabled

…then you will have to enable SELinux on your server, as it is currently disabled.

Else, SELinux should be enabled in your system and the output will state so. We will explore the meaning of this output in the next part of this series.

To enable SELinux, edit the /etc/sysconfig/selinux file. Initiate SELinux in ‘permissive’ mode:

SELINUX=permissive

And use the default targeted policy for SElinux rules:

SELINUXTYPE=targeted

Once you set these values, save the file and reboot your system.

File relabelling

Once you have enabled SELinux in your system, you will notice that on the next reboot, all files in your system will be labelled. Labelling for files is akin to applying Extended Attributes required by SELinux to your ext2/ext3 filesystem. This process may take some time, so be patient and let the complete reboot occur.

Checking Security Contexts

Upon reboot, log in to your shell and issue the ls command. Did you see any extended attributes? I doubt it. To see the Security Context of files and directories, use ls -Z. You will see an output similar to the one below, containing the extended attributes:

[vbg@vbg selinux]$ ls -lZ
-rw-rw-r-- vbg vbg user_u:object_r:user_home_t:s0 scratch-pad
-rw-rw-r-- vbg vbg user_u:object_r:user_home_t:s0 series-definition
-rw-rw-r-- vbg vbg user_u:object_r:user_home_t:s0 series-of-articles
-rw-rw-r-- vbg vbg user_u:object_r:user_home_t:s0 The-Art-Of-Guard.vbg

You can now see the Security Context of all files/folders in your system. In the above snippet, for the file scratch-pad, the DAC related attributes are: owner (vbg), group (vbg), and permissions (664); while the MAC related Extended Attributes (xattrs) that define the Security Context are:user_u:object_r:user_home_t:s0. The fourth attribute in the Security Context defines the sensitivity. We will discuss this fourth attribute in the later part of the series.

To check the ID of the logged in user, issue the command id -Z:

[vbg@vbg selinux]$ id -Z
user_u:system_r:unconfined_t:s0

The id command also gives the UID/GID of the user:

[vbg@vbg selinux]$ id
uid=500(vbg) gid=500(vbg) groups=500(vbg) context=user_u:system_r:unconfined_t:s0

To see a list of processes (subjects) with their security contexts, issue the ps auxZ command:

[vbg@vbg selinux]$ ps auxZ
user_u:system_r:unconfined_t:s0  3543 ?        Ss     0:01 /usr/bin/perl -T -w /usr/bin/spamd --socketpath /home/vbg/.evolu
user_u:system_r:unconfined_t:s0  3546 ?        S      0:02 spamd child
user_u:system_r:unconfined_t:s0  3730 pts/3    Ss     0:00 /bin/bash
user_u:system_r:unconfined_t:s0  3760 ?        S      0:00 knotify [kdeinit]
user_u:system_r:unconfined_t:s0  3762 pts/3    S+     0:02 vim The-Art-Of-Guard.vbg
user_u:system_r:httpd_t:s0      root      4227 41.0  1.4  42376 29216 pts/2    R+   14:46   0:01 /usr/sbin/httpd

Please note that each process has been assigned a Security Context. Do also note the type assigned to these subjects.

Try out the above introductory commands in SELinux. Explore… there is a wealth of information available on SELinux on the Web. Do not enforce a Strict Policy while you are not too sure about SELinux Policies, which we will cover in detail in the coming issues. If you end up in a state that your system will not boot satisfactorily or if you would simply like to disable SELinux at boot time, press e on your Grub screen to edit the boot sequence when rebooting. Edit the default kernel booting parameters by appending selinux=0 at the end of the line and continue to boot. This will temporarily disable SELinux and you will be back to traditional DAC security.