Mise en œuvre du contrôle d’accès obligatoire avec SELinux ou AppArmor sous Linux
Pour surmonter les limites et augmenter les mécanismes de sécurité fournis par les autorisations standard ugo/rwx et les listes de contrôle d’accès, la National Security Agency (NSA) des États-Unis a mis au point une méthode flexible de contrôle d’accès obligatoire (MAC) connue sous le nom de SELinux (abréviation de Security Enhanced Linux) afin de limiter, entre autres, la capacité des processus à accéder ou à effectuer d’autres opérations sur les objets système (tels que les fichiers, les répertoires, les ports réseau, etc.) avec le moins d’autorisation possible, tout en permettant des modifications ultérieures de ce modèle.
Un autre MAC populaire et largement utilisé est AppArmor, qui, en plus des fonctionnalités fournies par SELinux, comprend un mode d’apprentissage qui permet au système d'"apprendre » comment se comporte une application spécifique et de fixer des limites en configurant des profils pour une utilisation sûre de l’application.
Dans CentOS 7, SELinux est incorporé dans le noyau lui-même et est activé en mode Application par défaut (plus d’informations à ce sujet dans la section suivante), contrairement à openSUSE et Ubuntu qui utilisent AppArmor.
Dans cet article, nous allons vous expliquer l’essentiel de SELinux et AppArmor et comment utiliser l’un de ces outils à votre avantage en fonction de la distribution que vous avez choisie.
Introduction à SELinux et comment l’utiliser sur CentOS 7
Sécurité renforcée Linux peut fonctionner de deux manières différentes :
- Application : SELinux refuse l’accès en fonction des règles de politique SELinux, un ensemble de directives qui contrôlent le moteur de sécurité.
- Permissif : SELinux ne refuse pas l’accès, mais les refus sont enregistrés pour les actions qui auraient été refusées si elles avaient été exécutées en mode d’application.
SELinux peut également être désactivé. Bien qu’il ne s’agisse pas d’un mode de fonctionnement en soi, il s’agit toujours d’une option. Cependant, il vaut mieux apprendre à utiliser cet outil que de simplement l’ignorer. Gardez-le à l’esprit !
Pour afficher le mode actuel de SELinux, utilisez getenforce. Si vous souhaitez basculer le mode de fonctionnement, utilisez setenforce 0 (pour le définir sur Permissive) ou setenforce 1 (Enforcer).
Étant donné que cette modification ne survivra pas à un redémarrage, vous devrez modifier le fichier /etc/selinux/config et définir la variable SELINUX sur enforcer, permissive ou disabled afin d’obtenir une persistance entre les redémarrages :
D’ailleurs, si getenforce renvoie Disabled, vous devrez modifier /etc/selinux/config avec le mode de fonctionnement souhaité et redémarrer. Sinon, vous ne pourrez pas définir (ou basculer) le mode de fonctionnement avec setenforce.
L’une des utilisations typiques de setenforce consiste à basculer entre les modes SELinux (de l’application à la permissivité ou l’inverse) pour dépanner une application qui se comporte mal ou ne fonctionne pas comme prévu. Si cela fonctionne après avoir défini SELinux sur le mode permissif, vous pouvez être sûr que vous rencontrez un problème d’autorisations SELinux.
Deux cas classiques où nous aurons probablement affaire à SELinux sont :
- Modification du port par défaut sur lequel un démon écoute.
- Définition de la directive DocumentRoot pour un hôte virtuel en dehors de /var/www/html.
Jetons un coup d’œil à ces deux cas à l’aide des exemples suivants.
EXEMPLE 1 : Changer le port par défaut du démon sshd
L’une des premières choses que font la plupart des administrateurs système pour sécuriser leurs serveurs est de changer le port sur lequel le démon SSH écoute, principalement pour décourager les scanners de ports et les attaquants externes. Pour ce faire, nous utilisons la directive Port dans /etc/ssh/sshd_config suivie du nouveau numéro de port comme suit (nous utiliserons le port 9999 dans ce cas) :
Port 9999
Après avoir tenté de redémarrer le service et vérifié son état, nous verrons qu’il n’a pas réussi à démarrer :
systemctl restart sshd
systemctl status sshd
Si nous jetons un coup d’œil à /var/log/audit/audit.log, nous verrons que sshd a été empêché de démarrer sur le port 9999 par SELinux car il s’agit d’un port réservé au service de gestion JBoss (les messages de journal SELinux incluent le mot « AVC » afin qu’ils puissent être facilement identifiés des autres messages) :
cat /var/log/audit/audit.log | grep AVC | tail -1
À ce stade, la plupart des gens désactiveraient probablement SELinux, mais nous ne le ferons pas. Nous verrons qu’il y a un moyen pour SELinux, et sshd d’écouter sur un port différent, de vivre en harmonie ensemble. Assurez-vous que le paquet policycoreutils-python est installé et exécutez-le :
yum install policycoreutils-python
Pour afficher la liste des ports sur lesquels SELinux autorise l’écoute de sshd. Dans l’image suivante, nous pouvons également voir que le port 9999 a été réservé à un autre service et que nous ne pouvons donc pas l’utiliser pour exécuter un autre service pour le moment :
semanage port -l | grep ssh
Bien sûr, nous pourrions choisir un autre port pour SSH, mais si nous sommes certains que nous n’aurons pas besoin d’utiliser cette machine spécifique pour des services liés à JBoss, nous pouvons alors modifier la règle SELinux existante et attribuer ce port à SSH à la place :
semanage port -m -t ssh_port_t -p tcp 9999
Après cela, nous pouvons utiliser la première commande semanage pour vérifier si le port a été correctement attribué, ou les options -lC (abréviation de list custom) :
semanage port -lC
semanage port -l | grep ssh
Nous pouvons maintenant redémarrer SSH et nous connecter au service en utilisant le port 9999. Notez que ce changement survivra à un redémarrage.
EXEMPLE 2 : Choix d’un DocumentRoot en dehors de /var/www/html pour un hôte virtuel
Si vous devez configurer un hôte virtuel Apache à l’aide d’un répertoire autre que /var/www/html en tant que DocumentRoot (par exemple, /websrv/sites/gabriel/public_html) :
DocumentRoot “/websrv/sites/gabriel/public_html”
Apache refusera de diffuser le contenu car le index.html a été étiqueté avec le type SELinux default_t, auquel Apache ne peut pas accéder :
wget http://localhost/index.html
ls -lZ /websrv/sites/gabriel/public_html/index.html
Comme dans l’exemple précédent, vous pouvez utiliser la commande suivante pour vérifier qu’il s’agit bien d’un problème lié à SELinux :
cat /var/log/audit/audit.log | grep AVC | tail -1
Pour changer le libellé de /websrv/sites/gabriel/public_html de manière récursive en httpd_sys_content_t, procédez comme suit :
semanage fcontext -a -t httpd_sys_content_t "/websrv/sites/gabriel/public_html(/.*)?"
La commande ci-dessus accordera à Apache un accès en lecture seule à ce répertoire et à son contenu.
Enfin, pour appliquer la politique (et faire en sorte que le changement d’étiquette entre en vigueur immédiatement), faites ce qui suit :
restorecon -R -v /websrv/sites/gabriel/public_html
Vous devriez maintenant pouvoir accéder à l’annuaire :
wget http://localhost/index.html
Pour plus d’informations sur SELinux, reportez-vous au guide SELinux et administrateur de Fedora 22.