Lorsque l’on installe un serveur Centos 7 et que l’on active SELinux, on est par défaut dans la politique targeted. Cette politique, bien que déjà suffisante, ne répond pas à toutes les problématiques que l’on pourrait avoir sur un serveur. En effet, le fait de laisser des modules en unconfined peut clairement être un problème de sécurité.
Donc, la première chose à faire est d’installer une politique plus contraignante certes, mais surtout beaucoup plus restrictive.
Je préconise de passer directement en MLS avant d’installer les autres programmes. En effet, il est plus simple de résoudre les problèmes un par un, que de tous les avoir d’un seul coup.
# yum install selinux-policy-mls.noarch
Ce paquet ne vient pas tout seul
[root@ postfix]# yum deplist selinux-policy-mls.noarch
Modules complémentaires chargés : fastestmirror
Loading mirror speeds from cached hostfile
* base: centos.mirrors.ovh.net
* epel: ftp.nluug.nl
* extras: centos.mirrors.ovh.net
* updates: centos.mirrors.ovh.net
paquet : selinux-policy-mls.noarch 3.13.1-102.el7_3.15
dépendance : /bin/bash
provider: bash.x86_64 4.2.46-21.el7_3
dépendance : /bin/sh
provider: bash.x86_64 4.2.46-21.el7_3
dépendance : coreutils
provider: coreutils.x86_64 8.22-18.el7
dépendance : policycoreutils >= 2.5
provider: policycoreutils.x86_64 2.5-11.el7_3
dépendance : policycoreutils-newrole >= 2.5
provider: policycoreutils-newrole.x86_64 2.5-11.el7_3
dépendance : selinux-policy = 3.13.1-102.el7_3.15
provider: selinux-policy.noarch 3.13.1-102.el7_3.15
dépendance : setransd
provider: mcstrans.x86_64 0.3.4-5.el7
Une fois cette politique installée, il faut aller modifier le fichier /etc/selinux/config et modifier la politique chargée pour mettre mls. Il est important de ne pas mettre la configuration en enforcing, sinon, le serveur risque de pas redémarrer.
Puis, il faudra installer policycoreutils-python-2.5-11.el7_3.x86_64 pour pouvoir manipuler les contextes de sécurité. Ce paquet nous sera nécessaire par la suite.
Il faut associer un compte utilisateur classique (celui qui administrera le serveur) à l’utilisateur SELinux staff_u. Ainsi, l’utilisateur devrait changer de rôle pour devenir sysadm_r pour pouvoir faire les actions d’administration.
Pourquoi le mettre dans staff_u et non en sysadm_u ? Simplement parce que SELinux va interdire la connexion en SSH des comptes associés à l’utilisateur SELinux sysadm_u. Ce paramètre est modifiable en manipulant les booléens SELinux, mais ce n’est pas conseillé.
Avant de redémarrer, il est nécessaire que SELinux relabellise le système de fichiers pour que les nouveaux contextes de sécurité soient appliqués. Pour cela, il suffit de taper
# touch /.autorelabel
Et de redémarrer le serveur. Le redémarrage va être plus long qu’un démarrage classique puisque le système va devoir parcourir entièrement le système de fichiers.
Premiers problèmes
Après la relabellisation et donc le redémarrage, certains fichiers ne possèdent pas le bon contexte de sécurité. Soit parce que le script de relabellisation n’a pas fonctionné correctement, soit parce que les fichiers ont été créés après le mécanisme. Dans tous les cas, vous aurez des erreurs et surtout, des restes de contextes de sécurité unconfined. Pour résoudre ce premier problème, il suffit de taper :
# restorecon -Rv /
Cette commande va forcer la relabellisation du système de fichiers.
Une fois cette première étape passée, vous allez sûrement installer des applications (serveur HTTP, MySQL, etc.). Cependant, vous allez être confrontés à ce genre de message et ce, malgré la relabellisation du système de fichiers.
type=AVC msg=audit(1488804756.793:6136): avc: denied { read } for pid=18603 comm="fail2ban-server" name="localtime" dev="sda1" ino=654211 scontext=system_u:system_r:fail2ban_t:s0-s15:c0.c1023 tcontext=system_u:object_r:locale_t:s15:c0.c1023 tclass=lnk_file
Pour résoudre ce problème, vous serez peut-être tenté de taper la commande magique (audit2allow) qui va lire le contenu des fichiers de logs SELinux et proposer une solution. Mais il se pourrait que l’erreur suivante apparaisse :
[root@ conf.d]# audit2allow -a
[Errno 2] Aucun fichier ou dossier de ce type: '/etc/selinux/mls/contexts/files/file_contexts.local'
Oupss… Bon, la résolution est assez simple puisqu’il suffit de créer le fichier file_contexs.local, même vide, pour que l’outil fonctionne correctement.
La solution au premier problème la plus naturelle est la suivante :
allow fail2ban_t locale_t:lnk_file { read };
Alors oui, il faut installer le paquet selinux-policy-devel (même si l’ANSSI dit que non, mais c’est nécessaire à la compilation et à la manipulation des politiques SELinux).
[root@ modules]# yum deplist selinux-policy-devel
Modules complémentaires chargés : fastestmirror
Determining fastest mirrors
* base: fr.mirror.babylon.network
* epel: fr.mirror.babylon.network
* extras: fr.mirror.babylon.network
* updates: fr.mirror.babylon.network
paquet : selinux-policy-devel.noarch 3.13.1-102.el7_3.15
dépendance : /bin/sh
provider: bash.x86_64 4.2.46-21.el7_3
dépendance : /usr/bin/make
provider: make.x86_64 1:3.82-23.el7
dépendance : checkpolicy >= 2.5
provider: checkpolicy.x86_64 2.5-4.el7
dépendance : m4
provider: m4.x86_64 1.4.16-10.el7
dépendance : policycoreutils-devel >= 2.5
provider: policycoreutils-devel.x86_64 2.5-11.el7_3
provider: policycoreutils-devel.i686 2.5-11.el7_3
dépendance : selinux-policy = 3.13.1-102.el7_3.15
provider: selinux-policy.noarch 3.13.1-102.el7_3.15
Mais cela ne suffira pas. En effet, vous allez avoir une violation d’une contrainte MLS puisque le lien symbolique est dans une sensibilité s15 et votre processus n’est qu’en s0-s15.
Il existe, au moins, deux solutions pour résoudre ce problème. La première, bien bourrine et qui peut laisser quelques failles de sécurité :
mls_file_read_all_levels(fail2ban_t);
Bon, la, on autorise le domaine fail2ban_t a contourné toute la politique MLS sur l’ensemble du système. Et surtout, vous allez avoir le même problème avec les autres applications qui ont besoin de lire la timezone (genre httpd ou maridb, toutes les applications dans la vraie vie). Donc, il va falloir autoriser l’ensemble des applications à contourner la politique MLS.
La seconde consiste à modifier le contexte de sécurité du lien symbolique et du fichier cible. Pour cela, on va taper les commandes suivantes :
chcon -hv system_u:object_r:locale_t:s0 /etc/localtime
chcon -hv system_u:object_r:locale_t:s0 /usr/share/zoneinfo/Europe/Paris
Avec cette méthode, il n’y a plus de violation des propriétés MLS.
Dernier point par rapport à ce premier post, il m’est arrivé de faire tout simplement crasher audit2allow sans trop savoir pourquoi. Ma supposition est que le fichier d’audit était bien trop gros (~8Mo) pour le programme, mais ce n’est qu’une supposition. La seule solution est de supprimer le fichier et de redémarrer le service d’audit.
