Série RHCSA : Principes de base du contrôle d’accès obligatoire avec SELinux dans RHEL 7 - Partie 13

Au cours de cette série, nous avons exploré en détail au moins deux méthodes de contrôle d’accès : les autorisations standard ugo/rwx (Gérer les utilisateurs et les groupes – Partie 3) et les listes de contrôle d’accès (Configurer les listes de contrôle d’accès sur les systèmes de fichiers – Partie 7).

Bien qu’ils soient nécessaires en tant que mécanismes d’autorisation et de contrôle d’accès de premier niveau, ils présentent certaines limitations qui sont résolues par Security Enhanced Linux (alias SELinux en abrégé).

L’une de ces limitations est qu’un utilisateur peut exposer un fichier ou un répertoire à une faille de sécurité par le biais d’une commande chmod mal élaborée et ainsi provoquer une propagation inattendue des droits d’accès. Par conséquent, tout processus démarré par cet utilisateur peut faire ce qu’il veut avec les fichiers qu’il possède, où enfin un logiciel malveillant ou autrement compromis peut obtenir un accès de niveau racine à l’ensemble du système.

C’est avec ces limitations à l’esprit que la National Security Agency (NSA) des États-Unis a d’abord conçu SELinux, une méthode de contrôle d’accès obligatoire flexible, pour restreindre 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.) au modèle de moindre autorisation, qui peut être modifié ultérieurement si nécessaire. En quelques mots, chaque élément du système ne reçoit que l’accès nécessaire pour fonctionner.

Dans RHEL 7, SELinux est incorporé dans le noyau lui-même et est activé par défaut en mode Application. Dans cet article, nous allons expliquer brièvement les concepts de base associés à SELinux et à son fonctionnement.

Modes SELinux

SELinux peut fonctionner de trois 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.
Désactivé (explicite).

La commande getenforce affiche le mode actuel de SELinux, tandis que setenforce (suivi d’un 1 ou d’un 0) est utilisé pour changer le mode en Enforcing ou Permissive, respectivement, pendant la session en cours uniquement.

Afin d’obtenir une persistance lors des déconnexions et des redémarrages, vous devrez modifier le fichier /etc/selinux/config et définir la variable SELINUX sur enforcer, permissive ou disabled :

# getenforce
setenforce 0
getenforce
setenforce 1
getenforce
cat /etc/selinux/config

En règle générale, vous utiliserez setenforce pour basculer entre les modes SELinux (application à permissive et inversement) comme première étape de dépannage. Si SELinux est actuellement configuré pour s’appliquer pendant que vous rencontrez un certain problème, et que la même chose disparaît lorsque vous le définissez sur permissif, vous pouvez être sûr que vous rencontrez un problème d’autorisations SELinux.

Contextes SELinux

Un contexte SELinux se compose d’un environnement de contrôle d’accès où les décisions sont prises en fonction de l’utilisateur, du rôle et du type SELinux (et éventuellement d’un niveau) :

Un utilisateur SELinux complète un compte d’utilisateur Linux standard en le mappant à un compte d’utilisateur SELinux, qui à son tour est utilisé dans le contexte SELinux pour les processus de cette session, afin de définir explicitement leurs rôles et niveaux autorisés.
Le concept de rôle agit comme un intermédiaire entre les domaines et les utilisateurs SELinux en ce sens qu’il définit les domaines de processus et les types de fichiers auxquels il est possible d’accéder. Cela protégera votre système contre les attaques de vulnérabilité aux attaques par élévation de privilèges.
Un type définit un type de fichier SELinux ou un domaine de processus SELinux. Dans des circonstances normales, les processus ne peuvent pas accéder aux fichiers utilisés par d’autres processus, ni accéder à d’autres processus, de sorte que l’accès n’est autorisé que s’il existe une règle de politique SELinux spécifique qui l’autorise.

Voyons comment tout cela fonctionne à travers les exemples suivants.

EXEMPLE 1 : Changer le port par défaut du démon sshd

Dans Sécuriser SSH – Partie 8, nous avons expliqué que changer le port par défaut sur lequel sshd écoute est l’une des premières mesures de sécurité pour sécuriser votre serveur contre les attaques externes. Modifions le fichier /etc/ssh/sshd_config et définissons le port sur 9999 :

Port 9999

Enregistrez les modifications et redémarrez sshd :

# systemctl restart sshd
systemctl status sshd

Comme vous pouvez le voir, sshd n’a pas réussi à démarrer. Mais que s’est-il passé ?

Une inspection rapide de /var/log/audit/audit.log indique que sshd s’est vu refuser les autorisations de démarrage sur le port 9999 (les messages de journal SELinux incluent le mot « AVC » afin qu’ils puissent être facilement identifiés des autres messages) car il s’agit d’un port réservé pour le service de gestion JBoss :

# cat /var/log/audit/audit.log | grep AVC | tail -1

À ce stade, vous pouvez désactiver SELinux (mais ne le faites pas !) comme expliqué précédemment et essayer de redémarrer sshd, et cela devrait fonctionner. Cependant, l’utilitaire semanage peut nous dire ce que nous devons changer pour que nous puissions démarrer sshd dans n’importe quel port que nous choisissons sans problème.

Courir

# semanage port -l | grep ssh

pour obtenir la liste des ports sur lesquels SELinux autorise l’écoute en sshd.

Changeons donc le port dans /etc/ssh/sshd_config en Port 9998, ajoutons le port au contexte ssh_port_t, puis redémarrons le service :

# semanage port -a -t ssh_port_t -p tcp 9998
systemctl restart sshd
systemctl is-active sshd

Comme vous pouvez le voir, le service a démarré avec succès cette fois-ci. Cet exemple illustre le fait que SELinux contrôle le numéro de port TCP selon ses propres définitions internes de type de port.

EXEMPLE 2 : Autoriser httpd à envoyer l’accès sendmail

Voici un exemple de SELinux gérant un processus accédant à un autre processus. Si vous deviez implémenter mod_security et mod_evasive avec Apache dans votre serveur RHEL 7, vous devez autoriser httpd à accéder à sendmail afin d’envoyer une notification par courrier à la suite d’une attaque (D)DoS. Dans la commande suivante, omettez l’indicateur -P si vous ne souhaitez pas que la modification soit persistante entre les redémarrages.

# semanage boolean -1 | grep httpd_can_sendmail
setsebool -P httpd_can_sendmail 1
semanage boolean -1 | grep httpd_can_sendmail

Comme vous pouvez le voir dans l’exemple ci-dessus, les paramètres booléens SELinux (ou simplement booléens) sont des règles vrai/faux intégrées dans les politiques SELinux. Vous pouvez lister tous les booléens avec semanage boolean -l, et alternativement le diriger vers grep afin de filtrer la sortie.

EXEMPLE 3 : Servir un site statique à partir d’un répertoire autre que celui par défaut

Supposons que vous diffusiez un site Web statique à l’aide d’un répertoire différent de celui par défaut (/var/www/html), par exemple /websites (cela peut être le cas si vous stockez vos fichiers Web dans un lecteur réseau partagé, par exemple, et que vous devez le monter dans /websites).

a). Créez un fichier index.html à l’intérieur de /websites avec le contenu suivant :

<html>
<h2>SELinux test</h2>
</html>

Si c’est le cas,

# ls -lZ /websites/index.html

vous verrez que le fichier index.html a été étiqueté avec le type SELinux default_t, auquel Apache ne peut pas accéder :

b). Remplacez la directive DocumentRoot dans /etc/httpd/conf/httpd.conf par /websites et n’oubliez pas de mettre à jour le bloc Directory correspondant. Ensuite, redémarrez Apache.

c). Naviguez jusqu’à http://<adresse IP du serveur Web>, et vous devriez obtenir une réponse HTTP 503 Forbidden.

d). Ensuite, remplacez l’étiquette de /websites, de manière récursive, par le type httpd_sys_content_t afin d’accorder à Apache un accès en lecture seule à ce répertoire et à son contenu :

# semanage fcontext -a -t httpd_sys_content_t "/websites(/.*)?"

e). Enfin, appliquez la politique SELinux créée en d) :

# restorecon -R -v /websites

Maintenant, redémarrez Apache et naviguez à nouveau jusqu’à http://<adresse IP du serveur Web> et vous verrez le fichier html s’afficher correctement :

Résumé

Dans cet article, nous avons passé en revue les bases de SELinux. Notez qu’en raison de l’immensité du sujet, une explication complète et détaillée n’est pas possible dans un seul article, mais nous pensons que les principes décrits dans ce guide vous aideront à passer à des sujets plus avancés si vous le souhaitez.

Si vous me le permettez, permettez-moi de vous recommander deux ressources essentielles pour commencer : la page NSA SELinux et le Guide de l’utilisateur et de l’administrateur RHEL 7 SELinux.

N’hésitez pas à nous faire savoir si vous avez des questions ou des commentaires.