La traduction de l'article est préparée pour les étudiants du cours «Sécurité Linux»

SELinux ou Security Enhanced Linux est un mécanisme de contrôle d'accès avancé, développé par la National Security Agency des États-Unis (NSA) pour prévenir les intrusions malveillantes. Il implémente un modèle de contrôle d'accès obligatoire (Mandatory Access Control, MAC) au-dessus d'un modèle de contrôle d'accès discrétionnaire (Discretionary Access Control, DAC) existant, c'est-à-dire des autorisations de lecture, d'écriture et d'exécution.

SELinux a trois modes :

1. Enforcing — interdiction d'accès sur la base des règles de la politique.
2. Permissive — tenue d'un journal des actions enfreignant la politique, qui seraient interdites en mode enforcing.
3. Activée — désactivation complète de SELinux.

Par défaut, les paramètres sont dans /etc/selinux/config

Modification des modes de SELinux

Pour connaître le mode actuel, exécutez

$ getenforce

Pour changer le mode en permissive, exécutez la commande suivante

$ setenforce 0

ou, pour passer du mode permissive sur enforcing, exécutez

$ setenforce 1

Si vous devez désactiver complètement SELinux, cela ne peut se faire que par le fichier de configuration

$ vi /etc/selinux/config

Pour le désactiver, modifiez le paramètre SELINUX comme suit :

SELINUX=disabled

Configuration de SELinux

Chaque fichier et processus est marqué par un contexte SELinux, qui contient des informations supplémentaires, telles que l'utilisateur, le rôle, le type, etc. Si vous activez SELinux pour la première fois, vous devez d'abord configurer le contexte et les labels. Le processus d'assignation des labels et du contexte est connu sous le nom de marquage. Pour commencer le marquage, modifiez le mode dans le fichier de configuration à permissive.

$ vi /etc/selinux/config
SELINUX=permissive

Après avoir défini le mode permissive, créons dans la racine un fichier caché vide nommé .autorelabel

$ touch /.autorelabel

et redémarrez l'ordinateur

$ init 6

Remarque : nous utilisons le mode permissive pour le marquage, car l'utilisation du mode enforcing peut entraîner un plantage du système lors du redémarrage.

Ne vous inquiétez pas si le démarrage se bloque sur un fichier, le marquage prend un certain temps. Une fois le marquage et le démarrage de votre système terminés, vous pouvez retourner au fichier de configuration et définir le mode enforcing, et également exécuter :

$ setenforce 1

Vous avez maintenant activé SELinux avec succès sur votre ordinateur.

Surveillance des journaux

Il est possible que vous ayez rencontré des erreurs lors du marquage ou pendant le fonctionnement du système. Pour vérifier si SELinux fonctionne correctement et s'il ne bloque pas l'accès à un port, une application, etc., vous devez consulter les journaux. Le journal de SELinux se trouve dans /var/log/audit/audit.log, mais vous n'avez pas besoin de le lire entièrement pour trouver des erreurs. Vous pouvez utiliser l'outil audit2why pour rechercher des erreurs. Exécutez la commande suivante :

$ audit2why < /var/log/audit/audit.log

En conséquence, vous obtiendrez une liste d'erreurs. S'il n'y avait pas d'erreurs dans le journal, aucun message ne s'affichera.

Configuration de la politique SELinux

La politique SELinux est un ensemble de règles que suit le mécanisme de sécurité SELinux. La politique définit un ensemble de règles pour un environnement spécifique. Nous allons maintenant voir comment configurer des politiques pour autoriser l'accès à des services interdits.

1. Valeurs logiques (commutateurs)

Les commutateurs (booléens) permettent de modifier des parties de la politique en cours d'exécution, sans avoir besoin de créer de nouvelles politiques. Ils permettent de faire des changements sans redémarrer ou recompresser les politiques SELinux.

Exemple
Supposons que nous souhaitions fournir un accès partagé au répertoire personnel d'un utilisateur par FTP en lecture et écriture, et que nous l'ayons déjà partagé, mais que lors de la tentative d'accès, nous ne voyons rien. Cela est dû au fait que la politique SELinux interdit au serveur FTP de lire et d'écrire dans le répertoire personnel de l'utilisateur. Nous devons modifier la politique pour que le serveur FTP puisse accéder aux répertoires personnels. Vérifions s'il existe des commutateurs pour cela en exécutant

$ semanage boolean -l

Cette commande produira une liste des commutateurs disponibles avec leur état actuel (activé/on ou désactivé/off) et leur description. Vous pouvez affiner votre recherche en ajoutant grep pour trouver les résultats se rapportant uniquement à ftp :

$ semanage boolean -l | grep ftp

et vous trouverez ce qui suit

ftp_home_dir -> off       Permet au ftp de lire et d'écrire des fichiers dans le répertoire personnel de l'utilisateur

Ce commutateur est désactivé, donc nous allons l'activer avec setsebool ftp_home_dir on

Maintenant, notre démon ftp pourra accéder au répertoire personnel de l'utilisateur.
Remarque : vous pouvez également obtenir une liste des commutateurs disponibles sans description en exécutant getsebool -a

2. Étiquettes et contexte

C'est le moyen le plus courant de mettre en œuvre la politique SELinux. Chaque fichier, dossier, processus et port est étiqueté avec un contexte SELinux :

• Pour les fichiers et dossiers, les étiquettes sont stockées en tant qu'attributs étendus dans le système de fichiers et peuvent être consultées avec la commande suivante :

  $ ls -Z /etc/httpd

• Pour les processus et ports, l'étiquetage est géré par le noyau, et vous pouvez voir ces étiquettes de la manière suivante :

processus

$ ps –auxZ | grep httpd

port

$ netstat -anpZ | grep httpd

Exemple
Maintenant, examinons un exemple pour mieux comprendre les étiquettes et le contexte. Supposons que nous ayons serveur web, qui remplace le répertoire /var/www/html/ использует /home/dan/html/. SELinux considérera cela comme une violation de la politique, et vous ne pourrez pas consulter vos pages Web. Cela est dû au fait que nous n'avons pas défini le contexte de sécurité associé aux fichiers HTML. Pour voir le contexte de sécurité par défaut, utilisez la commande suivante :

$ ls –lz /var/www/html
 -rw-r—r—. root root unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/

Ici, nous avons obtenu httpd_sys_content_t comme contexte pour les fichiers HTML. Nous devons définir ce contexte de sécurité pour notre répertoire actuel, qui possède maintenant le contexte suivant :

-rw-r—r—. dan dan system_u:object_r:user_home_t:s0 /home/dan/html/

Commande alternative pour vérifier le contexte de sécurité d'un fichier ou d'un répertoire :

$ semanage fcontext -l | grep '/var/www'

Nous utiliserons également semanage pour modifier le contexte, après avoir trouvé le bon contexte de sécurité. Pour modifier le contexte /home/dan/html, exécutez les commandes suivantes :

$ semanage fcontext -a -t httpd_sys_content_t '/home/dan/html(/.*)?'
$ semanage fcontext -l | grep '/home/dan/html'
/home/dan/html(/.*)? tous les fichiers system_u:object_r:httpd_sys_content_t:s0
$ restorecon -Rv /home/dan/html

Après que le contexte ait été modifié avec semanage, la commande restorecon chargera le contexte par défaut pour les fichiers et répertoires. Notre serveur Web pourra maintenant lire les fichiers du dossier /home/dan/html, puisque le contexte de sécurité pour ce dossier a été modifié en httpd_sys_content_t.

3. Création de politiques locales

Il peut y avoir des situations où les méthodes ci-dessus ne vous sont d'aucune utilité, et vous obtenez des erreurs (avc/denial) dans audit.log. Lorsque cela se produit, il faut créer une politique locale (Local policy). Vous pouvez trouver toutes les erreurs à l'aide de audit2why, comme décrit ci-dessus.

Pour résoudre les erreurs, on peut créer une politique locale. Par exemple, si nous rencontrons une erreur liée à httpd (apache) ou smbd (samba), nous filtrons les erreurs et créons une politique pour elles :

apache
$ grep httpd_t /var/log/audit/audit.log | audit2allow -M http_policy
samba
$ grep smbd_t /var/log/audit/audit.log | audit2allow -M smb_policy

Ici http_policy et smb_policy sont les noms des politiques locales que nous avons créées. Nous devons maintenant charger ces politiques locales dans la politique SELinux en cours. Cela peut être fait de la manière suivante :

$ semodule –I http_policy.pp
$ semodule –I smb_policy.pp

Nos politiques locales ont été chargées, et nous ne devrions plus recevoir d'avc ou de denial dans audit.log.

C'était ma tentative de vous aider à comprendre SELinux. J'espère qu'après avoir lu cet article, vous vous sentirez plus à l'aise avec SELinux.

Source : habr.com