Recherche de site Web

Implémentation du contrôle d'accès obligatoire avec SELinux ou AppArmor sous Linux

Pour surmonter les limitations et augmenter les mécanismes de sécurité fournis par les autorisations ugo/rwx standard et les listes de contrôle d'accès, la Agence nationale de sécurité des États-Unis (NSA) a conçu un système flexible Méthode de contrôle d'accès obligatoire (MAC) connue sous le nom de SELinux (abréviation de Security Enhanced Linux) afin de restreindre entre autres la capacité des processus à accéder ou effectuer d'autres opérations sur les objets système (tels que des fichiers, des répertoires, des ports réseau, etc.) avec le moins d'autorisations 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, inclut un mode d'apprentissage qui permet au système « apprendre » comment se comporte une application spécifique et de définir des limites en configurant des profils pour une utilisation sécurisée de l'application.

Dans CentOS 7, SELinux est intégré au noyau lui-même et est activé par défaut en mode Enforcing (plus d'informations à ce sujet dans la section suivante), contrairement à openSUSE et Ubuntu qui utilisent AppArmor.

Dans cet article, nous expliquerons l'essentiel de SELinux et AppArmor et comment utiliser l'un de ces outils à votre bénéfice en fonction de la distribution choisie.

Introduction à SELinux et comment l'utiliser sur CentOS 7

Linux à sécurité améliorée peut fonctionner de deux manières différentes :

  1. 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é.
  2. Permissif : SELinux ne refuse pas l'accès, mais les refus sont enregistrés pour les actions qui auraient été refusées s'ils étaient exécutés en mode d'application.

SELinux peut également être désactivé. Bien qu’il ne s’agisse pas d’un mode de fonctionnement en soi, cela reste une option. Cependant, il vaut mieux apprendre à utiliser cet outil que de simplement l’ignorer. Garde le en mémoire!

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 (Enforcing).

É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 soit enforcing, permissive ou disabled afin d'obtenir la persistance lors des redémarrages :

En passant, si getenforce renvoie Disabled, vous devrez éditer /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 enforcing à permissive ou inversement) 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 en mode Permissif, vous pouvez être sûr que vous êtes confronté à un problème d'autorisations SELinux.

Deux cas classiques où nous aurons très probablement affaire à SELinux sont :

  1. Modification du port par défaut sur lequel un démon écoute.
  2. 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 : Modification du port par défaut pour le démon sshd

L'une des premières choses que font la plupart des administrateurs système pour sécuriser leurs serveurs est de modifier 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 œil à /var/log/audit/audit.log, nous verrons que sshd n'a pas pu démarrer sur le port 9999. par SELinux car il s'agit d'un port réservé pour le service JBoss Management (les messages du journal SELinux incluent le mot « AVC » afin qu'ils puissent être facilement identifié à partir d’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 existe un moyen pour SELinux et sshd écoutant sur un port différent de vivre en harmonie ensemble. Assurez-vous que le package policycoreutils-python est installé et exécutez :


yum install policycoreutils-python

Pour afficher une liste des ports sur lesquels SELinux autorise sshd à écouter. Dans l'image suivante, nous pouvons également voir que le port 9999 était réservé à un autre service et 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 les 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 : Choisir un DocumentRoot en dehors de /var/www/html pour un hôte virtuel

Si vous devez configurer un hôte virtuel Apache en utilisant un répertoire autre que /var/www/html comme 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 default_t SELinux, 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 :


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 rendre le changement d'étiquette effectif immédiatement), procédez :


restorecon -R -v /websrv/sites/gabriel/public_html

Vous devriez maintenant pouvoir accéder au répertoire :


wget http://localhost/index.html

Pour plus d'informations sur SELinux, reportez-vous au guide Fedora 22 SELinux et administrateur.