SELinux Overview: Speaking of Security.
By Linux and storage specialist Artjom Averin and SQL programmer and Linux specialist Valeria Nossova.
Introduction
SELinux (stands for security-enhanced Linux) is a powerful mechanism that allows to keep processes in the system under control and prevent them from performing inappropriate operations. It has been developed by National Security Agency (NSA) in the US for the needs of government and military information infrastructures. A decision of its development and implementation was made in order to establish a new standard of IT security, a system these structures could rely on.
Later SELinux source code was presented to the public and since version 2.6 it is included into Linux kernel. In general, this means that it is possible to set up SELinux access control system on every Linux distribution, however on some of them it will be a bit of a challenge. There are certain distributions like RedHat, CentOS or Fedora, where SELinux works out-of-the box, in some others, like Ubuntu and Debian, SELinux essential packages are included in official repositories by default. Our favourite Linux system is CentOS and some specifics of this distribution branchwill be present in this article.
Access control
Since the very first Linux distributions a discretionary access control, DAC was used to secure the system. As it is initial model, it is now classic, used and known everywhere. It became very flexible and useful; it is possible to provide recursive rights, to use SGID, SUID or T bit, to group accesses and so on. It seems to be quite self-sufficient, but using some imagination makes it clear that just DAC is not enough.
Then Access Control List, ACL was developed. Not only it allows setting up permission for an owner, group and others – it also enables to set up different permissions for various users or groups. For example,now a file can be accessed by the owner, users in group1, in group2, but neither by users in group3 nor by the others. It is impossible to make it work with the classic DAC model.
One of the disadvantages of this system could be described using a simple example. Suppose, some user executes a program to perform some calculations with his files in /home/user/files folder. In the same moment a cracker was lucky to find vulnerability in the program and to get into the system through that program process. By default that process inherits user accesses to the system and not only a cracker will be able to mess up with the information in /home/user/files folder, but also with /home/user folder and every single file a user has access to in the system.
SELinux makes it strict – this program(and its process)will only have a limited to the needs access to /home/user/files folder, not more. Of course, it is inconvenient to rely on SELinux only, this is why its settings are applied after classic DAC/ACL permission check and no matter what setting you have in SELinux, if DAC says you have no access – this is how it will remain.
Definitions
Subject – a user or process,which performs actions
Object – the thing, to which this action is being performed. Commonly, it is file data, nevertheless programs or even devices could also be presented as objects.
Domain – list of actions, which could be performed by the subject.
Role–a list of domains,which could be applied.
Type – a list of actions,which could be performed to the object.
Security context – all attributes of SELinux: roles, types, domains.
Policy – a list of rules specifying the rights of the subject with a certain domain to access an object of a certain type.
SELinux approach to access management
In SELinux permissions are defined by rule containers called policies. Policies work on the kernel level and it is nearly impossible to crack them keeping the operation system alive. In general, policies contain more than 100 000 rules, thus its creation and configuration takes significant period of time. Most common are the following policies:
Targeted – this policy was developed by Red Hat Company and is very popular. Processes included in this policy are dhcpd, httpd (apache.te), named, nscd, ntpd, portmap, snmpd, squid, and syslogd.It is easy to set up, but every process which is not described in this policy will, in fact, be run within unlimited domain unconfined_t not controlled by SELinux. This is the weakest point of Targeted policy.
MLS, Multi-level security policy makes it possible to define permissions based on object secrecy label.
Strict – a policy, presuming rule ‘everything that is not allowed is denied’. It is unique to every system, because any process which is not described within the policy will simply not work. Obviously, all systems have their own lists of processes, this is why the policy has to be configured separately on every system.
There are also three modes used with SELinux:
Enforcing – SELinux is enabled, processes act according to the policy.
Permissive – SELinux is enabled, but does not prevent any processes from performing any insecure actions. This is a default mode for CentOS distributions. It is used first of all for testing purposes. When deploying some service, it might be a good idea to switch SELinux to permissive mode at some point and see, whether the service is not working due to some policy settings. In this mode it will work, but all rule breaking actions will be logged.
Disabled is a self-explanatory mode.
Some words about configuration
All of the above settings are available in configuration file in /etc/selinux/config. Here is an example:
# 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.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
# targeted – Targeted processes are protected,
# mls – Multi Level Security protection.
SELINUXTYPE=targeted
You could also set mode by running a following command, replacing mode by one of the available modes (enforcing/permissive/disabled):
# setenforce mode
This command allows you to switch quickly between enforcing and permissive modes, however, if you decide to switch it off with setenforce disabled, you would have to reboot. Any time you can easily find out, which mode you are currently using by running the following command:
# getenforce
Or, to get status of all settings:
# 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: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28
As has already been said, you can check SELinux logs in order to view insecure actions performed in permissive mode. Logs are stored in a /var/log/messagesfile and it would be a good idea to search by phrase, for example:
# grep “SELinux is preventing” /var/log/messages
Another logging file is located at /var/log/audit/audit.log and is also very popular.
Would you like to list SELinux context of a file,you should execute command ls with flag -Z:
# ls -Z /etc/shadow
-rw-r–r–. root rootsystem_u:object_r:passwd_file_t:s0 /etc/passwd
Blue part of the output is the classic DAC configuration, green one is the security context. It is written as domain:role:type:MLS_parameter. As far as MLS system is not usable on CentOS out-of-the-box, feel free to ignore it.
Same flag is applicable to a process list command:
#ps axZ | grep bluetoothd
system_u:system_r:bluetooth_t:s0 2695 ? Ss 0:00 /usr/sbin/bluetoothd -n
Conclusion
To sum up, a SELinux system is a mighty access management system. Investing time into configuring it will result in a super-secure system, which is even suitable for military IT. In the next part of the article we will cover configuration of SELinux in more detail and we hope that it will make you to stop thinking of SELinux as of annoying non-usable service breaker.