SELinux was developed as an additional Linux security solution that uses the security framework in the Linux kernel. The purpose was to allow for a more granular security policy that goes beyond what is offered by the default existing permissions of Read Write and Execute, and also beyond assigning permissions to the different capabilities that are available on Linux. SELinux does this by trapping all syscalls that reach the kernel, and denying them by default. This means that on a system that has SELinux enabled and nothing else configured, nothing will work. To allow your system to do anything, as an administrator you will need to write rules and put them in a policy.
An example explains why a solution such as SELinux (or its counterpart AppArmor) is needed.
One morning, I found out that my server was hacked. The server was
running SLES 10 SP 3 server, which was patched up to the latest
level. A firewall was configured on it and no unnecessary services were
offered by this server. Further analysis learned that the hacker had come
in through a flaky PHP script that was a part of one of the Apache
virtual hosts that were running on this server. The intruder had managed
to get access to a shell, using the
account that was used by the Apache Web server. As this
wwwrun user, the intruder had
created several scripts in the /var/tmp and the
/tmp directories, which were a part of a botnet that
was launching a Distributed Denial of Service attack against different
servers on the planet.
The interesting thing about this hack is that it occurred on a server where nothing was really wrong. All permissions where set OK, but the intruder had managed to get into the system. What becomes clearly evident from this example is that in some cases additional security is needed—a security that goes beyond what is offered by using SELinux. As a less complete and less complex alternative, AppArmor can be used.
AppArmor confines specific processes in their abilities to read/write and execute files (and other things). Its view is mostly that things that happen inside a process cannot escape.
SELinux instead uses labels attached to objects (e.g. files, binaries, network sockets) and uses them to determine privilege boundaries, thereby building up a level of confinement that can span more than a process or even the whole system.
SELinux was developed by the US National Security Agency (NSA), and since the beginning Red Hat has been heavily involved in its development. The first version of SELinux was offered in the era of , around the year 2006. In the beginning it offered support for essential services only, but over the years it has developed into a system that offers many rules that are collected in policies to offer protection to a broad range of services.
SELinux was developed in accordance with some certification standards like Common Criteria and FIPS 140. Because some customers specifically requested solutions that met these standards, SELinux rapidly became relatively popular.
As an alternative to SELinux, Immunix, a company that was purchased by Novell in 2005, had developed AppArmor. AppArmor was built on top of the same security principles as SELinux, but took a completely different approach, where it was possible to restrict services to exactly what they needed to do by using an easy to use wizard-driven procedure. Nevertheless, AppArmor has never reached the same status as SELinux, even if there are some good arguments to secure a server with AppArmor rather than with SELinux.
Because more and more governmental organizations currently are requesting SELinux to be present in the Linux distributions they are using, SUSE is offering support for the SELinux framework in the latest versions of SUSE Linux Enterprise Server. This doesn’t mean that SUSE is about to switch from AppArmor to SELinux soon, for SUSE it is important that the customer can choose the security solution that fits his needs best.
Currently, the SELinux framework is supported in SUSE Linux Enterprise 11 SP2. This means that you can expect that SUSE Linux Enterprise is offering all binaries and libraries you need to be able to use SELinux on your server without any problems. A policy however is not included and you will also miss some binaries that you might be familiar with from using other Linux distributions. Some of these binaries are available at http://software.opensuse.org. It is however not a good idea to install them on your SUSE Linux Enterprise system as they haven’t been tested and therefore might cause additional problems to the system. Currently, SELinux support is at a fairly early stage on SUSE Linux Enterprise and this means that unexpected behavior may occur. To limit this risk as much as possible, it is a good idea to use only the binaries that have been provided by default on SLES 11 SP2.
Before starting the configuration of SELinux, you should know a bit about how SELinux is organized. Three components play a role:
The security framework in the Linux kernel
The SELinux libraries and binaries
The SELinux policy
SUSE Linux Enterprise 11 SP2 and later comes with the standard support for SELinux in the Linux kernel, and the tools that are needed to manage the SELinux solution. You will shortly learn how to install these tools on your server. The most important part of the work of the administrator with regards to SELinux is managing the policy.
In the SELinux policy, security labels are applied to different objects on a Linux server. These objects typically are users, ports, processes and files. Using these security labels, rules are created that define what is and what isn’t allowed on a server. Remember, by default SELinux denies all syscalls and by creating the appropriate rules you can allow the syscalls that you trust again. Rules should therefore exist for all programs that you want to use on a system. Alternatively, you might want to configure parts of a system to run in unconfined mode, which means that specific ports, programs, users, files and directories are not protected at all by SELinux. This mode is useful if you just want to use SELinux to protect some essential services, while you aren't specifically worried about other services. To get a really secure system, you should try to avoid this.
To ensure the appropriate protection of your system, you need an SELinux policy. This must be a tailor-made policy in which all files are provided with a label, and all services and users have a security label as well to express which files and directories can be accessed by which user and processed on the server. Developing such a policy is a tremendous amount of work. In SUSE Linux Enterprise, no policy is available yet. If you want to use SELinux, you have to take care of creating your own policy.
The complexity of SELinux is also one of the main arguments against using it. Because a typical Linux system is so very complex, it is easy to oversee something and leave an opening that intruders can abuse to get into your system. And even if it is set up completely the way it should be, it still is very hard for an administrator to overlook all aspects with SELinux. With regards to the complexity, AppArmor takes a completely different approach and works with automated procedures that allow the administrator to set up AppArmor protection and understand exactly what is happening.
In SUSE Linux Enterprise 11 SP2, the SELinux framework is supported and provided. The SELinux policy is not. Therefore, as an administrator that wishes to use SELinux on SUSE Linux Enterprise, you will have to create your own policy, or use one of the standard policies that are available for free. Do notice though that a freely available SELinux policy might work on your server, but it will never offer complete protection for all aspects of security on your server! Also, SUSE does not support these open source policies, which is obvious because they haven’t been developed by SUSE and they do not match SUSE. But in its current state you can use SELinux to protect SUSE Linux Enterprise Server.