: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, {{ic|audit2allow}} uses logs from this program.

=== Installation ===

=== Installation ===

Revision as of 07:43, 6 February 2014

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.

Deprecated. SELinux support now comes built in to the official kernel package

coreutils

Need a rebuild to link with libselinux

cronie

Need a rebuild with '--with-selinux' flag

findutils

Need SELinux patch, already upstream

openssh

Need a rebuild with '--with-selinux' flag

pam

Need a rebuild with '--enable-selinux' flag for Linux-PAM ; Need a patch for pam_unix2, which only removes a function already implemented in a library elsewhere

pambase

Configuration changes to add pam_selinux.so

psmisc

Need a patch, already upstream. Will be in version 22.21

shadow

Need a rebuild with '-lselinux' and '--with-selinux' flags

sudo

Need a rebuild with '--enable-selinux' flag

systemd

Need a rebuild with '--enable-selinux' flag

util-linux

Need a rebuild with '--enable-selinux' flag

All of the other SELinux related packages may be included without risks.

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.

SELinux policy packages

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

Installation

Only ext2, ext3, ext4, JFS, XFS and BtrFS filesystems are supported to use SELinux. Since the 3.13 kernel update, the options required for SELinux to work on any system are enabled in the default kernel configuration, hence there should be no problems by default. If you are using a custom kernel, please do make sure that Xattr (Extended Attributes), CONFIG_AUDIT and CONFIG_SECURITY_SELINUX are enabled in your config. (Source: Debian Wiki)

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

There are two methods to install the requisite SELinux packages.

Via Unofficial Repository

Add Siosm's SELinux repository to your pacman.conf and install the following by either using the su - command or by logging in as root:

Warning: Do not use the sudo command to install these. This is because pam, which is used for sudo authentication, is being replaced here

Via AUR

A lot of credit for this section must go to jamesthebard for his outstanding work and documentation.

The first install needs to be of pambase-selinuxAUR and pam-selinuxAUR. 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>.

Tip: The openssh-selinuxAUR package needs to be built in a gui environment else it fails in the pairs.sh test during compilation.

Now comes the 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. If it still isn't even after installing the package, run:

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:

# pam_selinux.so close should be the first session rule
session required pam_selinux.so close

# pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open

Installing a policy

Warning: The reference policy as given by Tresys is not very good for Arch Linux, as almost no file is labelled correctly. However, as of writing, Archers have no other choice. If anyone has made any significant strides in addressing this problem, they are encouraged to share it, preferably on the AUR.

Policies are the mainstay of SELinux. They are what govern its behaviour. The only policy currently available in the AUR is the Reference Policy. In order to install it, you should use the source files, which may be got from the package selinux-refpolicy-srcAUR. Change the pkgver to 20130424 and the sha256sums to 6039ba854f244a39dc727cc7db25632f7b933bb271c803772d754d4354f5aef4 and build the file. Now, navigate to /etc/selinux/refpolicy/src/policy and run the following commands:

# make bare
# make conf
# make install

to install the reference policy as it is. Those who know how to write SELinux policies can tweak them to their heart's content before running the commands written above. The command takes a while to do its job and taxes one core of your system completely, so don't worry. Just sit back and let the command run for as long as it takes.

Then, make the file /etc/selinux/config with the following contents (Only works if you used the defaults as mentioned above. If you decided to change the name of the policy, you need to tweak the file):

/etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# Set this value once you know for sure that SELinux is configured the way you like it and that your system is ready for deployment
# permissive - SELinux prints warnings instead of enforcing.
# Use this to customise your SELinux policies and booleans prior to deployment. Recommended during policy development.
# disabled - No SELinux policy is loaded.
# This is not a recommended setting, for it may cause problems with file labelling
SELINUX=permissive
# SELINUXTYPE= takes the name of SELinux policy to
# be used. Current options are:
# refpolicy (vanilla reference policy)
# <custompolicy> - Substitute <custompolicy> with the name of any custom policy you choose to load
SELINUXTYPE=refpolicy

This is required to remove a few messages from /var/log/audit/audit.log which are a nuisance to deal with in the reference policy. This is an ugly hack and it should be made very clear that the policy so installed simply patches the reference policy in order to hide the effects of incorrect labelling.

Post-installation steps

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

Working with SELinux

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:

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

user:role:type[:level]

To explain:

User: The SELinux user identity. This can be associated to one or more roles that the SELinux user is allowed to use.

Role: The SELinux role. This can be associated to one or more types the SELinux user is allowed to access.

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.

Level: This optional field can also be know as a range and is only present if the policy supports MCS or MLS.

This is important in case you wish to understand how to build your own policies, for these are the basic building blocks of SELinux. However, for most purposes, there is no need to, for the reference policy is sufficiently mature. However, if you are a power user or someone with very specific needs, then it might be ideal for you to learn how to make your own SELinux policies.

This is a great series of articles for someone seeking to understand how to work with SELinux.

Troubleshooting

Because of the way the installation is done, SELinux will output its messages to /var/log/audit/audit.log. Another place to look for SELinux errors is the systemd journal. In general, your audit.log messages will be many and varied, but you really want to look out for AVC messages, for they are the ones warning you of an SELinux policy transgression by a file or user. They look something like:

It is a good idea to learn how to use the audit2why and audit2allow commands. The first command will tell you what the cryptic messages in your audit.log actually mean while the second will translate them into installable policies. In order to transform all your audit.log error messages to a single policy called "examplemod", use the following commands:

There will be times when the audit2why command will simply tell you what to do along with the command needed to do so. In that case, simply copy-paste what you need to.

Useful tools

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

restorecon

Restores the context of a file/directory (or recursively with -R) based on any policy rules

chcon

Change the context on a specific file

audit2allow

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.