Understanding SELinux, Part 1

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.

Pages: 1 2 3


  1. shekhar sharma says:

    its amazing thanks for providing such a information………..

  2. Pawan says:

    Hi Sir,

    Thanks for such a great article,

    just to add on

    Selinux could also be enabled using file in ll /etc/selinux/config, the content of the file look similar to the /etc/sysconfig/selinux

    # This file controls the state of SELinux on the system.
    # SELINUX= can take one of these three values:
    # enforcing – SELinux security policy is enforced.
    # permissive – SELinux prints warnings instead of enforcing.
    # disabled – No SELinux policy is loaded.
    # SELINUXTYPE= can take one of these two values:
    # targeted – Targeted processes are protected,
    # minimum – Modification of targeted policy. Only selected processes are protected.
    # mls – Multi Level Security protection.

    However enabling SELINUX using this need a reload of the kernel and would not take effect until a reboot (Corrections are welcome)

    We could enable the selinux on the fly by amending files in its /proc like system, It may vary from distribution to distribution, the best way to find it

    [pawan@localhost PAWAN]$ sestatus
    SELinux status: enabled

    *** SELinuxfs mount: /sys/fs/selinux ****

    SELinux root directory: /etc/selinux
    Loaded policy name: targeted
    Current mode: enforcing
    Mode from config file: disabled
    Policy MLS status: enabled
    Policy deny_unknown status: allowed
    Max kernel policy version: 28

    The one highlighted with **** is the area of interest

    if you do a

    [pawan@localhost PAWAN]$ ll /sys/fs/selinux

    -rw-r–r–. 1 root root 0 Oct 1 09:59 enforce
    –w——-. 1 root root 0 Oct 1 09:59 disable

    You will a lot of file and dir, my area of interest is the enforce file

    just do

    [pawan@localhost PAWAN]$ sudo echo 1 > /sys/fs/selinux/enforce

    you need be root or need to elevate your privileges

    you are done it will do the trick, SELINUX is enabled to enforcing mode.


  1. Starting with Linux - [...] visit, or staying away from bad guys. And if you really got paranoid, you could lock yourself in a …

Leave a Reply

Your email address will not be published. Required fields are marked *