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 ACL sur les systèmes de fichiers – Partie 7).
Bien que nécessaires en tant que permissions de premier niveau et mécanismes de contrôle d’accès, ils présentent certaines limitations qui sont traitées par la Sécurité Renforcée de Linux (Security Enhanced Linux) (alias SELinux pour faire court).
Une de ces limitations est qu’un utilisateur peut exposer un fichier ou un répertoire à une violation de sécurité à travers une commande chmod mal élaborée et ainsi provoquer une propagation inattendue des droits d’accès. En conséquence, tout processus lancé par cet utilisateur peut faire ce qu’il veut avec les fichiers appartenant à l’utilisateur, où en fin de compte un logiciel malveillant ou compromis peut obtenir un accès de niveau racine à l’ensemble du système.
Avec ces limitations à l’esprit, l’Agence de Sécurité Nationale des États-Unis (United States National Security Agency) (NSA) 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, répertoires, ports réseau, etc.) au modèle de permission le moins élevé, qui peut être modifié ultérieurement selon les besoins. En quelques mots, chaque élément du système reçoit uniquement l’accès nécessaire à son fonctionnement.
Dans RHEL 7, SELinux est incorporé dans le noyau lui-même et est activé en mode Enforcing par défaut. Dans cet article, nous expliquerons brièvement les concepts de base associés à SELinux et son fonctionnement.
Modes SELinux
SELinux peut fonctionner de trois manières différentes :
- Enforcing : SELinux refuse l’accès en fonction des règles de la politique SELinux, un ensemble de directives qui contrôlent le moteur de sécurité.
- Permissive : SELinux n’interdit pas l’accès, mais les refus sont enregistrés pour les actions qui auraient été refusées en mode enforcing.
- Disabled (auto-explicatif).
La commande getenforce affiche le mode actuel de SELinux, tandis que la commande setenforce (suivie d’un 1 ou d’un 0) est utilisée pour changer le mode en Enforcing ou Permissive, respectivement, uniquement pendant la session en cours.
Pour assurer la persistance entre les déconnexions et les redémarrages, vous devrez modifier le fichier /etc/selinux/config et définir la variable SELINUX sur enforcing, permissive ou disabled :
# getenforce # setenforce 0 # getenforce # setenforce 1 # getenforce # cat /etc/selinux/config
Généralement, vous utiliserez setenforce pour basculer entre les modes SELinux (enforcing à permissive et vice versa) comme première étape de dépannage. Si SELinux est actuellement défini sur enforcing lorsque vous rencontrez un certain problème, et que celui-ci disparaît lorsque vous le définissez sur permissive, vous pouvez être sûr qu’il s’agit d’un problème de permissions SELinux.
Contextes SELinux
A SELinux context consists of an access control environment where decisions are made based on SELinux user, role, and type (and optionally a level):
- A SELinux user complements a regular Linux user account by mapping it to a SELinux user account, which in turn is used in the SELinux context for processes in that session, in order to explicitly define their allowed roles and levels.
- Le concept de rôle agit comme un intermédiaire entre les domaines et les utilisateurs SELinux en définissant quels domaines de processus et types de fichiers peuvent être accessibles. Cela protégera votre système contre les attaques de privilège d’escalade.
- A type defines an SELinux file type or an SELinux process domain. Under normal circumstances, processes are prevented from accessing files that other processes use, and and from accessing other processes, thus access is only allowed if a specific SELinux policy rule exists that allows it.
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 protéger 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 démarré. Mais que s’est-il passé ?
A quick inspection of /var/log/audit/audit.log indicates that sshd has been denied permissions to start on port 9999 (SELinux log messages include the word “AVC” so that they might be easily identified from other messages) because that is a reserved port for the JBoss Management service:
# cat /var/log/audit/audit.log | grep AVC | tail -1
À ce stade, vous pourriez désactiver SELinux (mais ne le faites pas !) comme expliqué précédemment et essayer de redémarrer sshd à nouveau, et cela devrait fonctionner. Cependant, l’utilitaire semanage peut nous indiquer ce que nous devons changer pour pouvoir démarrer sshd sur n’importe quel port que nous choisissons sans problème.
Exécutez
# semanage port -l | grep ssh
pour obtenir une liste des ports sur lesquels SELinux autorise sshd à écouter.
Modifions 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 constater, 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 pour ses propres définitions de type de port interne.
EXEMPLE 2 : Autoriser httpd à envoyer un accès sendmail
Il s’agit d’un exemple de SELinux gérant un processus accédant à un autre processus. Si vous deviez mettre en place 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 e-mail en cas d’attaque (D)DoS. Dans la commande suivante, omettez le drapeau -P si vous ne souhaitez pas que le changement soit persistant après un redémarrage.
# 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 booleens SELinux (ou simplement booleens) sont des règles vrai/faux intégrées dans les politiques SELinux. Vous pouvez lister tous les booleens avec semanage boolean -l, et les filtrer en utilisant grep.
EXEMPLE 3 : Servir un site statique à partir d’un répertoire autre que le répertoire par défaut
Supposons que vous servez un site web statique en utilisant un répertoire différent du répertoire par défaut (/var/www/html), disons /sites (ce pourrait être le cas si vous stockez vos fichiers web dans un lecteur réseau partagé, par exemple, et que vous devez le monter à l’emplacement /sites).
a). Create an index.html file inside /websites with the following contents:
<html> <h2>SELinux test</h2> </html>
Si tel est le cas,
# ls -lZ /websites/index.html
vous verrez que le fichier index.html a été étiqueté avec le type default_t SELinux, auquel Apache ne peut pas accéder :
b). Change the DocumentRoot directive in /etc/httpd/conf/httpd.conf to /websites and don’t forget to update the corresponding Directory block. Then, restart Apache.
c). Browse to http://<web server IP address>, and you should get a 503 Forbidden HTTP response.
d). Next, change the label of /websites, recursively, to the httpd_sys_content_t type in order to grant Apache read-only access to that directory and its contents:
# semanage fcontext -a -t httpd_sys_content_t "/websites(/.*)?"
e). Finally, apply the SELinux policy created in d):
# restorecon -R -v /websites
Maintenant redémarrez Apache et accédez à nouveau à http://<adresse IP du serveur web> et vous verrez que le fichier html s’affiche correctement :
Résumé
Dans cet article, nous avons abordé les bases de SELinux. Notez que, en raison de l’ampleur du sujet, une explication détaillée complète n’est pas possible dans un seul article, mais nous croyons que les principes décrits dans ce guide vous aideront à passer à des sujets plus avancés si vous le souhaitez.
Si je peux me permettre, laissez-moi vous recommander deux ressources essentielles pour commencer : la page NSA SELinux et le guide Utilisateur et Administrateur SELinux de RHEL 7.
N’hésitez pas à nous faire part de vos questions ou commentaires.
Source:
https://www.tecmint.com/selinux-essentials-and-control-filesystem-access/