From ArchWiki
Revision as of 15:58, 24 May 2013 by Genghizkhan91 (talk | contribs) (Checking PAM)
Jump to navigation Jump to search

Security-Enhanced Linux (SELinux) is a Linux feature that provides a variety of security policies, including U.S. Department of Defense style mandatory access controls (MAC), through the use of Linux Security Modules (LSM) in the Linux kernel. It is not a Linux distribution, but rather a set of modifications that can be applied to Unix-like operating systems, such as Linux and BSD.

Running SELinux under a Linux distribution requires three things: An SELinux enabled kernel, SELinux Userspace tools and libraries, and SELinux Policies (mostly based on the Reference Policy). Some common Linux programs will also need to be patched/compiled with SELinux features.

Concepts: Mandatory Access Controls

Note: This section is meant for beginners. If you know what SELinux does and how it works, feel free to skip ahead to the installation.

Before you enable SELinux, it is worth understanding what it does. Simply and succinctly, SELinux enforces Mandatory Access Controls (MACs) on Linux. In contrast to SELinux, the traditional user/group/rwx permissions are a form of Discretionary Access Control (DAC). MACs are different from DACs because security policy and its execution are completely separated.

An example would be the use of the sudo command. When DACs are enforced, sudo allows temporary privilege escalation to root, giving the process so spawned unrestricted systemwide access. However, when using MACs, if the security administrator deems the process to have access only to a certain set of files, then no matter what the kind of privilege escalation used, unless the security policy itself is changed, the process will remain constrained to simply that set of files. So if sudo is tried on a machine with SELinux running in order for a process to gain access to files its policy does not allow, it will fail.

Another set of examples are the traditional (-rwxr-xr-x) type permissions given to files. When under DAC, these are user-modifiable. However, under MAC, a security administrator can choose to freeze the permissions of a certain file by which it would become impossible for any user to change these permissions until the policy regarding that file is changed.

As you may imagine, this is particularly useful for processes which have the potential to be compromised, i.e. web servers and the like. If DACs are used, then there is a particularly good chance of havoc being wrecked by a compromised program which has access to privilege escalation.

For further information, do visit the MAC Wikipedia page.



This information was originally sourced from the Debian Wiki.

Only ext2, ext3, ext4, JFS, XFS and BtrFS filesystems are supported to use SELinux. Some filesystems have a few quirks which you should be aware of before migration, though:

  • BtrFS: Currently an autorelabel operation won't cover subvolumes on btrfs. You need to manually relabel the subvolume. Once it's labelled everything will work correctly.
Note: The XFS section may not be needed anymore
  • XFS: XFS users should use 512 byte inodes (the default is 256). SELinux uses extended attributes for storing security labels in files. XFS stores this in the inode, and if the inode is too small, an extra block has to be used, which wastes a lot of space and incurs performance penalties.
# mkfs.xfs -i size=512 /dev/sda1  (for example)
  • SquashFS: SquashFS supports xattr (which is required for SELinux file labeling) since kernel version 2.6.30.
  • ReiserFS: ReiserFS has partial support for SELinux as it supports extended attributes but not atomic labelling meaning that newly created files will not have a SELinux context. This makes using SELinux under ReiserFS quite painful. ReiserFS is therefore not supported by utilities like fixfiles, so you should first migrate to one of the above listed filesystems if you intend to use SELinux.

Also, please do make sure that Xattr (Extended Attributes) are enabled for your filesystems. To do that, you can issue the following command:

$zcat /proc/config.gz | grep -i <filesystem name>

<filesystem name> can be reiser, xfs, etc. Somewhere among the output should be something like:


If you just want to see what filesystems have extended attributes enabled, just issue:

$zcat /proc/config.gz | grep -i xattr

If the output says that your filesystems do not have xattrs enabled, you need to recompile the kernel to enable them. Also, if you wish to use ReiserFS despite the warnings given, also make sure that it has security labels enabled as a separate option.

Preparing the Kernel

By default, the Arch Kernel does not have the SELinux LSM enabled. To check, you can issue the command:

$ zcat /proc/config.gz | grep -i selinux

To which your output should be something of the sort:


if you have a stock kernel running. If you are in the mind to build a custom kernel, the following options should be enabled for maximum security, performance and effectiveness:


Save the file in the directory you're building the kernel and then modify the PKGBUILD such that it goes from this:

if [ "${CARCH}" = "x86_64" ]; then
    cat "${srcdir}/config.x86_64" > ./.config
    cat "${srcdir}/config" > ./.config

to this:

if [ "${CARCH}" = "x86_64" ]; then
    cat "${srcdir}/config.x86_64" > ./.config
    cat "${srcdir}/config" > ./.config
  cat /absolute/path/to/config.selinux-custom >> ./.config

If you know what you're doing, then you can remove anything relating to filesystems you do not plan to use.

Warning: If you've built a custom kernel which is not linux-selinuxAUR (e.g. linux-iceAUR or linux-pfAUR), then the various packages which have to be compiled may fail to do so because of the linux-selinux dependency. Make sure to remove that dependency while compiling those packages. However, be careful that the options mentioned above are enabled in your kernel configuration.

For those of you who do not wish to be bothered by kernel configuration or anything else regarding PKGBUILDs, simply install the package linux-selinuxAUR from the AUR.

Note: If using proprietary drivers, such as NVIDIA graphics drivers, you may need to rebuild them for custom kernels.

Installing SELinux

Package description

All SELinux related packages belong to the selinux group. The group selinux-system-utilities is a group of modified packages from the [core] repository. The group selinux-userspace contains packages from the SELinux Userspace project. Security policies belong to the selinux-policies group. Other packages are in the selinux-extras group. All the packages mentioned below are present in the AUR.

SELinux aware system utilities

SELinux enabled kernel. It's not really needed, however, installing it comes recommended if you aren't a kernel tweaker.
Modified coreutils package compiled with SELinux support enabled. It replaces the coreutils package
Flex version needed only to build checkpolicy. The normal flex package causes a failure in the checkmodule command. It replaces the flex package.
selinux-pamAUR and selinux-pambaseAUR
PAM package with and the underlying base package. They replace the pam and pambase packages respectively.
An SELinux aware version of Systemd. It replaces the systemd package.
Modified util-linux package compiled with SELinux support enabled. It replaces the util-linux package.
Patched findutils package compiled with SELinux support to make searching of files with specified security context possible. It replaces the findutils package.
Modified sudo package compiled with SELinux support which sets the security context correctly. It replaces the sudo package.
Psmisc package compiled with SELinux support; for example, it adds the -Z option to killall. It replaces the psmisc package.
Shadow package compiled with SELinux support; contains a modified /etc/pam.d/login file to set correct security context for user after login. It replaces the shadow package.
Fedora fork of Vixie cron with SELinux enabled. It replaces the cronie package.
Logrotate package compiled with SELinux support. It replaces the logrotate package.
OpenSSH package compiled with SELinux support to set security context for user sessions. It replaces the openssh package.

SELinux userspace utilities

Tools to build SELinux policy
Library for security-aware applications. Python bindings needed for semanage and setools now included.
Library for policy management. Python bindings needed for semanage and setools now included.
Library for binary policy manipulation.
SELinux core utils such as newrole, setfiles, etc.
A Python library for parsing and modifying policy source.

SELinux policy packages

Precompiled modular-otherways-vanilla Reference policy with headers and documentation but without sources.
Reference policy sources
Precompiled modular Reference policy with headers and documentation but without sources. Development Arch Linux Refpolicy patch included, but for now [February 2011] it only fixes some issues with /etc/rc.d/* labeling.
Note: The selinux-refpolicy-arch package was last updated in 2011, hence it seems doubtful that it is useful any longer.

Other SELinux tools

CLI and GUI tools to manage SELinux
This is the only package mentioned here which is available in the official repos. These are the user space utilities for storing and searching the audit records generated by the audit subsystem in the Linux kernel. SELinux (AVC) will log all denials using audit. Very useful in troubleshooting SELinux. Also audit2allow uses logs from this program.


The credit for this section must go to jamesthebard for his outstanding work and documentation.

Note: As of this writing (May 24, 2013), he deemed his guide incomplete. However, the author of this wiki section has followed his guide and observed no breakages or problems on his own system.

The first install needs to be of selinux-pambaseAUR and selinux-pamAUR. However, do not use yaourt -S selinux-pam selinux-pambase or use sudo after building to install the package. This is because pam is what handles authentication. Hence, it is best if the packages are built as an ordinary user using makepkg and installed by root using a simple pacman -U <packagename>.

Next, you need to build and install selinux-coreutilsAUR, selinux-usr-libsemanageAUR, selinux-shadowAUR, libcgroupAUR, selinux-usr-policycoreutilsAUR, selinux-cronieAUR, selinux-findutilsAUR, selinux-flexAUR, selinux-logrotateAUR, selinux-opensshAUR and selinux-psmiscAUR.

Tip: The selinux-opensshAUR package needs to be built in a gui environment else it fails in the test during compilation.

Next, the swig package needs to be downgraded to version 2.0.4-3, else the package selinux-setoolsAUR gives an error. The Arch Rollback machine may be used for the same.

Now comes the selinux-setoolsAUR package. For this, do make sure that you have the jdk7-openjdk package installed, in order for the JAVA_HOME variable to be set properly. Also, you need to edit the PKGBUILD in order for it to compile properly. Change the PKGBUILD around line 14 so that it looks as follows:


Next, backup your /etc/sudoers file. Install selinux-sudoAUR, selinux-systemdAUR, selinux-usr-checkpolicyAUR, selinux-util-linuxAUR, audit and selinux-refpolicyAUR. The installation of selinux-refpolicy takes a considerable time subject to the number of files you have, the speed of your processor, etc.


After the installation of needed packages, you have to set up a few things so that SELinux can be used.

Changing boot loader configuration

If you've installed a new kernel, make sure that you update your bootloader accordingly


Run the following command:

# grub-mkconfig -o /boot/grub/grub.cfg


Change your syslinux.cfg file by adding:

LABEL arch-selinux
         LINUX ../vmlinuz-linux-selinux
         APPEND root=/dev/sda2 ro
         INITRD ../initramfs-linux-selinux.img

at the end. Change "linux-selinux" to whatever kernel you are using.

Editing fstab

Add following to /etc/fstab:

# SELinuxFS
none   /sys/fs/selinux   selinuxfs   noauto   0   0

# For /run
tmpfs  /run   tmpfs  mode=0755,nosuid,nodev,rootcontext=system_u:object_r:var_run_t  0 0

Do not forget to create the mount point:

# mkdir -p /sys/fs/selinux

If your /tmp is a tmpfs mounted location, then add the following:

# For a tmpfs type /tmp:
tmpfs  /tmp  tmpfs  defaults,noexec,nosuid,rootcontext=system_u:object_r:tmp_t  0 0

This is required because it is labelled as system_u:object_r:tmpfs_t by SELinux, but most processes are configured to believe that the /tmp directory is labelled as system_u:object_r:tmp_t

Starting the Audit Daemon

Issue the following command to start the Audit Daemon:

# systemctl start auditd.service

For enabling it permanently at boot, issue:

# systemctl enable auditd.service

Checking the main SELinux configuration file

The main SELinux configuration file (/etc/selinux/config) is a part of the selinux-refpolicyAUR package currently in the AUR. Its default contents are as follows:

# 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= takes the name of SELinux policy to
# be used. Current options are:
#       refpolicy (vanilla reference policy)
#       refpolicy-arch (reference policy with 
#       Arch Linux patch)

It is recommended to test your policies using the "SELINUX" parameter set to permissive. This does not actually enforce the policy but still logs everything to /var/log/audit/audit.log. You can check error messages here, and once you're convinced that everything is moving along smoothly, you can change the value of "SELINUX" to enforcing

Checking PAM

A correctly set-up PAM is important to get the proper security context after login. Check for the presence of the following lines in /etc/pam.d/system-login:

# close should be the first session rule
session         required close
# open should only be followed by sessions to be executed in the user context
session         required open

Now restart your machine to boot into an SELinux enabled environment.

Reference policy

The Reference Policy is now the standard policy source used to build SELinux policies. This provides a single source tree with supporting documentation that can be used to build policies for different purposes such as: confining important daemons, supporting MLS / MCS type policies and locking down systems so that all processes are under SELinux control.

There are currently two possible ways of installing reference policies: From a pre-compiled package (selinux-refpolicyAUR) or from the source package (selinux-refpolicy-srcAUR).

Note: It is possible to have both the source and the binary packages installed. If you plan to build from source, you should probably change the name of policy in build.conf to avoid overwriting of the selinux-refpolicy package files.

Installing a precompiled refpolicy

Install selinux-refpolicyAUR from AUR. This is a the vanilla SELinux reference policy. This package includes policy headers (you can therefore compile your own modules), policy documentation and an install script which will load the policy for you and relabel your filesystem (which will likely take some time). It does not include any sources.

This package also includes the main SELinux configuration file (/etc/selinux/config) defaulting to refpolicy and permissive SELinux enforcement for testing purposes.

You should verify that the policy was correctly loaded, i.e. /etc/selinux/refpolicy/policy/policy.26 has non-zero size. If so and if you have installed selinux-systemdAUR and other needed packages, you are ready to reboot and make sure that everything works.

In case the policy was not correctly loaded you can issue the following commands:

<nowki># cd /usr/share/selinux/refpolicy
# /bin/ls *.pp 

To manually relabel your filesystem you can issue:

# /sbin/restorecon -r /

SELinux Security Context

SELinux defines security using a different mechanism than traditional Unix access controls. The best way to understand it is by example. For example, the SELinux security context of the apache homepage looks like the following:

$ls -Z /var/www/html/index.html
-rw-r--r--  username username system_u:object_r:httpd_sys_content_t /var/www/html/index.html

The first three and the last columns should be familiar to any (Arch) Linux user. The fourth column is new and has the format:


To explain:

  1. User: The SELinux user identity. This can be associated to one or more roles that the SELinux user is allowed to use.
  2. Role: The SELinux role. This can be associated to one or more types the SELinux user is allowed to access.
  3. Type: When a type is associated with a process, it defines what processes (or domains) the SELinux user (the subject) can access. When a type is associated with an object, it defines what access permissions the SELinux user has to that object.
  4. Level: This optional field can also be know as a range and is only present if the policy supports MCS or MLS.

Post-installation steps

Warning: If you did not install selinux-systemd, then you will see SELinux in disabled mode, and /sys/fs/selinux will not be mounted.

You can check that SELinux is working with sestatus. You should get something like:

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             refpolicy
Current mode:                   permissive
Mode from config file:          permissive
Policy MLS status:              disabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

To maintain correct context, you can use restorecond:

# systemctl enable restorecond

To switch to enforcing mode without reboot, you can use:

# echo 1 >/selinux/enforce

Useful tools

There are some tools/commands that can greatly help with SELinux.

Restores the context of a file/directory (or recursively with -R) based on any policy rules
Relabels any files belonging to that Gentoo package to their proper security context (if they have one)
Change the context on a specific file
Reads in log messages from the AVC log file and tells you what rules would fix the error. Do not just add these rules without looking at them though, they cannot detect errors in other places (e.g. the application is running in the wrong context in the first place), or sometimes things will generate error messages but may maintain functionality so it would be better to add dontaudit to just ignore the access attempts.


See also

  • AppArmor (Similar to SELinux, much easier to configure, less features.)