Seasoned Linuxadministrators and security engineers already know that they need to put some trust in the users and processes of their system in order for the system to remain secure. This is partly because users can attempt to exploit vulnerabilities found in the software running on the system, but a large contribution to this trust level is because the secure state of the system depends on the behavior of the users. A Linux user with access to sensitive information could easily leak that out to the public, manipulate the behavior of the applications they launch, and do many other things that affect the security of the system. The default access controls active on a regular Linux system arediscretionary; it is upto the users how the access controls should behave.
The Linuxdiscretionary access control (DAC)mechanism is based on the user and/or groupinformation of the process and is matched against the user and/or group information of the file, directory, or other resource being manipulated. Consider the/etc/shadowfile, which contains the password and account information of the local Linux accounts:
$ ls -l /etc/shadow
-rw-r-----. 1 root root 1019 Nov 28 20:44 /etc/shadowWithout additionalaccess control mechanisms in place, this file is readable and writable by any process owned by therootuser, regardless of the purpose of the process on the system. Theshadowfile is a typical example of a sensitive file that we don’t want to see leaked or abused in any other fashion. Yet the moment someone has access to the file, that user can copy it elsewhere, for example to a home directory, or even mail it to another computer and attempt to attack the password hashes stored within.
Another example of how Linux DAC requires trust from its users is the configuration of a database server. Database files themselves are (hopefully) only accessible to the runtime account of thedatabase management system(DBMS) itself, and the Linuxrootuser. Properlysecured systems will only grant trusted users access to these files (for instance, throughsudo) by allowing them to change their effective user ID from their personal user to the database runtime user or even therootaccount, but only for a well-defined set of commands that the system administrator has configured up front. These users too, can analyze the database files and gain access to potentially confidential information in the database without going through the DBMS. Administrators often have to put significant trust in these users to provide a secure system, rather than being able to enforce this.
However, regular users are not the only reason for securing a system. Lots of software daemons run as the Linuxrootuser or have significant privileges on the system. Errors within those daemons can easily lead to information leakage or might even lead to remotely exploitable vulnerabilities. Backup software, monitoring software, change management software, scheduling software, and so on: they all often run with the highest privileged account possible on a regular Linux system. Even when the administrator does not allow privileged users, their interaction with daemons introduces a potential security risk. So, the users are still trusted to correctly interact with these applications in order for the system to function properly. Through this, the administrator leaves the security of the system to thediscretionof its (many) users.
Enter SELinux, which provides an additional access control layeron top ofthe standard Linux DAC mechanism. SELinux provides amandatory access control (MAC)system that, unlikeits DAC counterpart, gives the administrator full control over what is allowed on the system and what isn’t. It accomplishes this by supporting a policy-driven approach over what processes are and aren’t allowed to do and by enforcing this policy through the Linux kernel.
Mandatorymeans thatthe operating system enforces the access control, defined solely by the policy rules that the system administrator (or security administrator) has enabled. Users and processes do not have permission to change the security rules, so they cannot work aroundthe access controls; security is not left to their discretion anymore.
Considering the relational database example, a mandatory access control system would no longer require the administration to trust certain users, as it has full control over what these users can and cannot do.
The wordmandatoryhere, just like the worddiscretionarybefore, was not chosen accidentally to describe the abilities of the access control system: both are known terms in the securityresearch field. Many security publications use these terms, including theTrusted Computer System Evaluation Criteria(TSEC) (http://csrc.nist.gov/publications/history/dod85.pdf) standard (also known as theOrange Book) published by the Department of Defense in the United States of America in 1985. This publication has led to the Common Criteria standard for computer security certification (ISO/IEC 15408), available athttp://www.commoncriteriaportal.org/cc/.
Next, we’ll describe how the Linux kernel is responsible for the SELinux implementation.
Introducing Linux Security Modules (LSM)
Consider the example of the shadow file again. A MAC system can be configured to only allow a limited number of processes to read from and write to the file. On such specifically configured systems, a user logged on as root cannot directly access the file or even move it around. They can’t even change the attributes of the file:
# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),
4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video) context=sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
# cat /etc/shadow
cat: /etc/shadow: Permission denied
# chmod a+r /etc/shadow
chmod: changing permissions of '/etc/shadow': Permission deniedThe system enforces this through rules that describe when the contents of this file can be read, or when its attributes can be changed. With SELinux, these rules are defined in the SELinux policy and are loaded when the system boots. It is the Linux kernel itself that is responsible for enforcing the rules.
Mandatory access control systems such as SELinux are supported in the Linux kernel throughLinux Security Modules(LSM), a Linux subsystemcalled before processing a user space request. Such requests are calledsystem calls, and Linux supports over 100 of them.
LSM has been available in the Linux kernel since version 2.6, released in December 2003. It is a framework that provides hooks inside the Linux kernel at various locations, including the system call entry points. When these hooks trigger, registered security implementations such as SELinux have their functions executed automatically. In SELinux, thesefunctions check the policy and other information before returning a go/no-go. LSM by itself does not provide any security functionality; instead, it relies on security implementations that do the heavy lifting: the framework ismodular.
Within the LSM framework, two types of security modules exist: exclusive and non-exclusive modules. Two exclusive modules cannot be active simultaneously: each exclusive LSM module needs exclusive control over some kernel objects (generally those related to a security context) and is not able to deal with other LSM modules that need these objects as well. Non-exclusive modules don’t have this need and can be combined (also known asstacking) at will, regardless of whether an exclusive LSM module is active or not.
A major use case for stacking LSM modules is to enable different security models within containers running on the system. Right now, it is not possible to implement a different security module within a Linux container, and the security within the container falls back to the security module of the host. To support this, more and more exclusive LSM implementations (like SELinux) are working to make their implementation non-exclusive, and wecan expect improvements in this area within the next year.
SELinux is one implementation that uses LSM. Several other implementations exist:
- AppArmoris amandatory access control system that has a strong focus on application-level protections (called profiles), based largely on filesystem paths. This makes AppArmor easy to understand and implement for administrators, as it does not have the complexity of abstracting rules to labels (as SELinux does). In theLabeling all resources and objectssection, we explain why SELinux uses labels. AppArmor is an exclusive LSM module at the time of writing, but will most likely become non-exclusive very soon.
- Smackis a mandatoryaccess control system that uses labels on processes and resources. The labels contain security identifiers interpreted by Smack to enforce access control, requiring fewer access rules in Smack (unlike SELinux, which does not perform an interpretation of labels – excluding sensitivity – and thus requires a higher number of policy rules). Smack is an exclusive LSM module.
- TOMOYO Linuxis a mandatory access control system, but its access control mechanism isalso easy to use for system analysis. It automatically builds up policies based on application behavior, and like AppArmor, its policies primarily use paths rather than labels. TOMOYO Linux (and its fork,AKARI) is anon-exclusive LSM module.
- LoadPinis an LSMmodule that ensures that the Linux kernel resources (such as kernel modules and firmware) are all loaded from a single non-writable filesystem. LoadPin is a non-exclusive LSM module.
- Yamais an LSM module that adds additional access controls on activities that are not sufficientlyfine-grained by Linux, such as by attaching them to the memory of another process (using
ptrace). Yama is a non-exclusive LSM module. - SafeSetIdis an LSMmodule that allows finer control over which users can use
setuid(switching to another user) toward another user. Rather than granting the use ofsetuid, SafeSetId can limit for which users this is allowed. This ensures that vulnerabilities or misconfigurations in tools such assudoare still contained. SafeSetId is a non-exclusive LSM module. - Lockdownis an LSMmodule that protects the Linux kernel memory. It has two modes: in integrity mode, it prevents modifying kernel objects from user space (such as direct memory access or PCI access); in confidentiality mode, it additionally prevents extracting potentially confidential information from kernel objects. Lockdown is a non-exclusive LSM module.
- ThecapabilityLSMmodule is, by default, enabled on systems and provides support for Linux capabilities (a set of permissions granted to a user when the user is assigned a certain capability). It is a non-exclusive LSM module.
To query the list of active LSM modules on a system, read /sys/kernel/security/lsm:
$ cat /sys/kernel/security/lsm
capability,selinuxNext, we’ll explain how SELinux works on top of regular Linux access controls.
Extending regular DAC with SELinux
SELinux doesnot change the LinuxDAC implementation, nor can it override denials made by the Linux DAC permissions. If a regular system (without SELinux) prevents a particular access, there is nothing SELinux can do to override this decision. This is because the LSM hooks are triggeredafterthe regular DAC permission checks execute, a conscious design decision from the LSM project.
For instance, if you need to allow an additional user access to a file, you cannot add an SELinux policy to do that for you. Instead, you will need to look into other features of Linux, such as the use of POSIX access control lists. Through thesetfaclandgetfaclcommands, the user can set additional permissions on files and directories, opening up the selected resource to additional users or groups.
As an example, let’s grant a useradminread-write access to a file usingsetfacl:
$ setfacl -m u:admin:rw /srv/backup/setup.confSimilarly, to view the current POSIX ACLs applied to the file, use this command:
$ getfacl /srv/backup/setup.conf
getfacl: Removing leading '/' from absolute path names
# file: srv/backup/setup.conf
# owner: root
# group: root
user::rw-
user::admin:rw-
group::r--
mask::rw-
other::r—This shows that the file is writable not only by its owner but also by the admin user.
Restricting root privileges
The regular Linux DAC allows an all-powerful user:root. Unlike most other users on the system, thelogged-onrootuser has all the rights needed to fully manage the entire system, ranging from overriding access controls to controlling audits, changing user IDs, managing the network, and much more. This is supported through a securityconcept calledcapabilities(for an overview of Linux capabilities, check out the capabilities manual page:man capabilities). SELinux is also able to restrict access to these capabilities in a fine-grained manner.
Due to this fine-grained authorization aspect of SELinux, even therootuser can be confined without impacting the operations on the system. The previous example of accessing/etc/shadowis just one example of an activity that a powerful user such asrootstill might not be able to perform due to the SELinux access controls in place.
Reducing the impact of vulnerabilities
If onebenefit of SELinux needs to be stressed, then it is its ability to reduce the impact of vulnerabilities. But this vulnerability reduction is also often misunderstood.
A properly written SELinux policy confines applications so that their allowed activities are reducedto a minimum set. Thisleast-privilege modelensures that abnormal application behavior is not only detected and audited but also prevented. Many application vulnerabilities can be exploited to execute tasks that an application is not meant to do. When this happens, SELinux will prevent this.
However, there are two misconceptions about SELinux’s ability to thwart exploits, namely, the impact of the policy and the exploitation itself.
If the policy is not written in a least-privilege model, then SELinux might consider this non-standard behavior as normal and allow the actions to continue. For policy writers, this means that their policy rules have to be very fine-grained. Sadly, that makes writing policies very time-consuming: with more than 130 classes and over 250 permissions known to SELinux, policy rules need to take all these classes and permissions into account for each interaction.
As a result, policies tend to become convoluted and harder to maintain. Some policy writers make policies more permissive than is absolutely necessary, which might result in exploits becoming successful even though the action is not expected behavior from an application’s point of view.
The second misconception is the exploit itself. If an application’s vulnerability allows an unauthenticated user to use the application services as if the user were a regular, authorized user, then SELinux will not play a role in reducing the impact of the vulnerability; it will only notice the behavior of the application itself and not of the sessions internal to the application. As long as the application itself behaves as expected (such as accessing its own files and not poking around in other filesystems), SELinux will happily allow the actions to take place.
It is only when the application starts behaving erratically that SELinux stops the exploit from continuing. SELinuxwill prevent exploits such asremote command execution (RCE)against applications that should not be executing random commands (such as database management systems or web servers, excludingCGI-like functionality), whereas session hijacking or SQL injection attacks are not controllable through SELinux policies.
Enabling SELinux support
EnablingSELinux on a Linux system is not just a matterof enabling the SELinux LSM module within the Linux kernel.
An SELinux implementation contains the following:
- The SELinux kernel subsystem, implemented in the Linux kernel through LSM
- Libraries, used by applications that need to interact with SELinux
- Utilities, used by administrators to interact with SELinux
- Policies, which define the access controls themselves
The libraries and utilities are bundled by the SELinux user space project (https://github.com/SELinuxProject/selinux). Next to the applications and libraries provided by the SELinux user space project, various components on a Linux system are updated with SELinux-specific code, including theinitsystem and several core utilities.
Because SELinux isn’t just a switch that needs to be toggled, Linux distributions that support it usually come with SELinux predefined and loaded: Fedora, CentOS, and Red Hat Enterprise Linux (with its derivatives, such as Oracle Linux) are well-known examples. Other supporting distributions might not automatically have SELinux enabled but can easily support it through the installation of additional packages (which is the case with Debian and Ubuntu), and others have a well-documented approach to how to convert a system to SELinux (for example, Gentoo and Arch Linux).
Throughout the book, we will show examples for Gentoo and CentOS 8 (which is based on the free software of the Red Hat Enterprise Linux releases and is sponsored by Red Hat). These two distributions have different implementation details, which allow us to demonstrate the full potential of SELinux. To ensure the commands used within this book are available, some SELinux support tools might need to be installed.
On Gentoo Linux, install at least the following packages:
# emerge app-admin/setools sys-apps/policycoreutilsOn CentOS Linux, install at least the following packages:
# yum install setools-console policycoreutils-python-utilsAs packages can change over time, it is sensible to look up which package provides a particular command.
Note:
If the mentioned packages no longer exist or do not cover all commands, please consult your distribution’s documentation on which software packages to install. Most distributions allow searching for the most appropriate package as well, such as with e-file in Gentoo, or yum whatprovides on CentOS or related distributions.
With the SELinux main functionality described, let’s look at how SELinux knows what is on the system, and which abstraction it uses to allow policies to be developed for a wide set of users.
