Chapter 22: Managing SELinux

Goal

Sommaire

Introduction to SELinux

Introduction

Since the earliest days of Linux, file permissions have been the standard method of securing Linux systems. In some cases, file permissions are just not enough for getting a secured server. Let’s take a look at an example:

One morning I found out that my server was hacked. An intruder had broken through a bad script on my web server and had obtained shell access as the httpd user. Using this file access, he managed to create thousands of little PHP scripts that were involved in a massive DDoS attack.

From a security perspective, it is interesting that nothing really was wrong with the security settings on this server. All permissions were set in a decent way, and the httpd user, like any other user on a Linux server, does have permissions to create files in /var/tmp, as in /tmp. So, what would have been a good solution to prevent this kind of problem?

You could, of course, argue that the administrator of the web server should have been doing a better job and should have been watching what the scripts on the server were doing. But that is not how Linux servers are normally used. The Linux server administrator does not know all the applications running on his server, and the application administrator does not understand enough about Linux to ensure that something like this can never happen.

Another solution is to apply further security measures. For instance, this specific situation would have been prevented if the permission to run program files from the /tmp and /var/tmp directory would have been taken away by using the noexec mount option. But even if that would have worked for this specific situation, it is not a good overall security solution that prevents applications from doing things they are not supposed to be doing.

That is why SELinux was invented. SELinux provides mandatory access control to a Linux server, where every system call is denied unless it has been specifically allowed. This chapter explains how to use SELinux to make sure that serious security incidents will never happen on your server.

Security Enhanced Linux (SELinux)

Understanding SELinux Working and Modes

If SELinux is enabled and nothing else has been configured, all system calls are denied. To specify what exactly is allowed, a policy is used. In this policy, rules define which source domain is allowed to access which target domain.

The source domain is the object that is trying to access something. Typically, this is a process or a user.

The target domain is the object that is accessed. Typically, that is a file, directory, or a network port to define exactly what is allowed; context labels are used. Using these labels is the essence of SELinux because these labels are used to define access rules.

SELinux Core Elements

On a Linux system, you can choose to enable or disable SELinux. When SELinux is enabled, kernel support for SELinux is loaded, and some applications that are SELinux aware change their behavior, because specific libraries are used on a system that has SELinux enabled. If SELinux is disabled, no SELinux activity will be happening at all. Changing between SELinux enabled and SELinux disabled mode requires a reboot of your system. This is because SELinux is a feature that is deeply interwoven with the Linux kernel.

If on a system SELinux is enabled, you can select to put SELinux in enforcing mode or in permissive mode. In enforcing mode, SELinux is fully operational and enforcing all SELinux rules in the policy. If SELinux is in permissive mode, all SELinuxrelated activity is logged, but no access is blocked. This makes SELinux permissive mode an excellent mode to do troubleshooting. Permissive mode is also a great way to do something and see the result from an SELinux perspective. That can help in building new and more efficient policies.

Principe

SELinux (Security Enhanced Linux) est un système de contrôle d’accès obligatoire (Mandatory Access Control) qui s’appuie sur l’interface Linux Security Modules fournie par le noyau Linux. Concrètement, le noyau interroge SELinux avant chaque appel système pour savoir si le processus est autorisé à effectuer l’opération concernée.

SELinux s’appuie sur un ensemble de règles (policy) pour autoriser ou interdire une opération. Ces règles sont assez délicates à créer, mais heureusement deux jeux de règles standards (targeted et strict) sont fournies pour éviter le plus gros du travail de configuration.

SELinux security Concept

Security Enhanced Linux (SELinux) is an additional layer of system security. A primary goal of SELinux is to protect user data from system services that have been compromised.

Configuration files and directories

SELinux Running Modes

Commands

Exercise: Manipulating SELinux Modes

1. Open a root console on your server and type getenforce . You’ll normally see that SELinux is in enforcing mode.

2. Type setenforce 0 and type getenforce again. SELinux now switches to permissive mode.

3. Open the file /etc/sysconfig/selinux with an editor and change the line SELINUX= so that it reads SELINUX=disabled . Reboot your server.

4. After rebooting, log in to a root shell again and type getenforce . You’ll see that SELinux is now in disabled mode.

5. Try using the command setenforce 1 . You’ll see the message “setenforce: SELinux is disabled.” You cannot switch between disabled and enforcing mode without rebooting your server.

6. Open the file /etc/sysconfig/selinux again and change the line SELINUX=disabled back to SELINUX=enforcing . Reboot your system again.

7. After rebooting, type sestatus -v and read current status information about SELinux.

SELinux context

SELinux Identities

semanage command

Installation

Commands

[root@lab ~]# semanage login -l liste les correspondances existantes entre identifiants d’utilisateurs et identités SELinux. Si un utilisateur n’a pas de correspondance explicite, il aura l’identité indiquée en face de __default__.

[root@lab ~]# semanage login -a -s user_u utilisateur va associer l’identité user_u à l’utilisateur.

[root@lab ~]# semanage login -a -s xguest_u utilisateur va associer l’identité xguest_u à l’utilisateur.

[root@lab ~]# semanage login -d utilisateur va retirer la correspondance affectée à l’utilisateur.

Chaque module SELinux fournit un ensemble de règles d’étiquetage des fichiers mais il est également possible de rajouter des règles d’étiquetage spécifiques afin de les adapter à un cas particulier. Ainsi pour rendre toute l’arborescence /srv/www/ accessible au serveur web on pourrait exécuter

La première commande enregistre la nouvelle règle d’étiquetage et la deuxième restaure les bonnes étiquettes en fonction des règles enregistrées. D’une manière similaire, les ports TCP/UDP sont étiquetés afin que seuls les démons correspondants puissent y écouter. Ainsi, si l’on veut que le serveur web puisse également écouter sur le port 8080, il faut exécuter la commande

[root@lab ~]# semanage port -m -t http_port_t -p tcp 8080

Exercise 21.2 Setting a Context Label on a Nondefault Apache Document Root