Procédure

1. Ouvrez le fichier /etc/selinux/config dans un éditeur de texte de votre choix, par exemple :

   # vi /etc/selinux/config

2. Configurez l'option SELINUX=permissive:

   # This file controls the state of SELinux on the system.
   # SELINUX= can take one of these three values:
   #       enforcing - SELinux security policy is enforced.
   #       permissive - SELinux prints warnings instead of enforcing.
   #       disabled - No SELinux policy is loaded.
   SELINUX=permissive
   # SELINUXTYPE= can take one of these two values:
   #       targeted - Targeted processes are protected,
   #       mls - Multi Level Security protection.
   SELINUXTYPE=targeted

3. Redémarrer le système :

   # reboot

Vérification

1. Après le redémarrage du système, confirmez que la commande getenforce renvoie Permissive:

   $ getenforce
   Permissive

Procédure

1. Ouvrez le fichier /etc/selinux/config dans un éditeur de texte de votre choix, par exemple :

   # vi /etc/selinux/config

2. Configurez l'option SELINUX=enforcing:

   # This file controls the state of SELinux on the system.
   # SELINUX= can take one of these three values:
   #       enforcing - SELinux security policy is enforced.
   #       permissive - SELinux prints warnings instead of enforcing.
   #       disabled - No SELinux policy is loaded.
   SELINUX=enforcing
   # SELINUXTYPE= can take one of these two values:
   #       targeted - Targeted processes are protected,
   #       mls - Multi Level Security protection.
   SELINUXTYPE=targeted

3. Enregistrez la modification et redémarrez le système :

   # reboot

   Au démarrage suivant, SELinux réétiquette tous les fichiers et répertoires du système et ajoute le contexte SELinux pour les fichiers et répertoires qui ont été créés lorsque SELinux était désactivé.

Vérification

1. Après le redémarrage du système, confirmez que la commande getenforce renvoie Enforcing:

   $ getenforce
   Enforcing

Procédure

1. Activer SELinux en mode permissif. Pour plus d'informations, voir Passer en mode permissif.

2. Redémarrez votre système :

   # reboot

3. Pour plus d'informations, voir Identification des refus SELinux.

4. Veillez à ce que les fichiers soient réétiquetés lors du prochain redémarrage :

   # fixfiles -F onboot

   Cela crée le fichier /.autorelabel contenant l'option -F.

   Avertissement

   Passez toujours en mode permissif avant d'entrer dans la commande fixfiles -F onboot. Cela permet d'éviter que le système ne démarre pas s'il contient des fichiers non étiquetés. Pour plus d'informations, voir RHBZ#2021835.

5. S'il n'y a pas de refus, passez en mode d'application. Pour plus d'informations, voir Modifier les modes SELinux au démarrage.

Vérification

1. Après le redémarrage du système, confirmez que la commande getenforce renvoie Enforcing:

   $ getenforce
   Enforcing

1. Configurez votre chargeur de démarrage pour ajouter selinux=0 à la ligne de commande du noyau :

   $ sudo grubby --update-kernel ALL --args selinux=0

2. Redémarrez votre système :

   $ reboot

Procédure

1. Entrez la commande suivante pour créer un nouvel utilisateur Linux nommé example.user:

   # useradd example.user

2. Pour attribuer un mot de passe à l'utilisateur Linux example.user:

   # passwd example.user
   Changing password for user example.user.
   New password:
   Retype new password:
   passwd: all authentication tokens updated successfully.

3. Déconnexion de la session en cours.
4. Connectez-vous en tant qu'utilisateur Linux example.user. Lorsque vous vous connectez, le module PAM pam_selinux fait automatiquement correspondre l'utilisateur Linux à un utilisateur SELinux (dans ce cas, unconfined_u) et met en place le contexte SELinux qui en résulte. L'interpréteur de commandes de l'utilisateur Linux est alors lancé avec ce contexte.

Vérification

1. Lorsque vous êtes connecté en tant qu'utilisateur example.user, vérifiez le contexte d'un utilisateur Linux :

   $ id -Z
   unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Procédure

1. Entrez la commande suivante pour créer un nouvel utilisateur Linux nommé example.user et l'associer à l'utilisateur SELinux staff_u:

   # useradd -Z staff_u example.user

2. Pour attribuer un mot de passe à l'utilisateur Linux example.user:

   # passwd example.user
   Changing password for user example.user.
   New password:
   Retype new password:
   passwd: all authentication tokens updated successfully.

3. Déconnexion de la session en cours.
4. Connectez-vous en tant qu'utilisateur de Linux example.user. L'interpréteur de commandes de l'utilisateur est lancé dans le contexte staff_u.

Vérification

1. Lorsque vous êtes connecté en tant qu'utilisateur example.user, vérifiez le contexte d'un utilisateur Linux :

   $ id -Z
   uid=1000(example.user) gid=1000(example.user) groups=1000(example.user) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023

Procédure

1. Affiche la liste des enregistrements de connexion SELinux. La liste affiche les correspondances entre les utilisateurs Linux et les utilisateurs SELinux :

   # semanage login -l
   
   Login Name    SELinux User  MLS/MCS Range   Service
   
   __default__   unconfined_u  s0-s0:c0.c1023       *
   root          unconfined_u  s0-s0:c0.c1023       *

2. Mapper l'utilisateur __default__, qui représente tous les utilisateurs sans correspondance explicite, à l'utilisateur SELinux user_u:

   # semanage login -m -s user_u -r s0 __default__

Vérification

1. Vérifiez que l'utilisateur __default__ est associé à l'utilisateur SELinux user_u:

   # semanage login -l
   
   Login Name    SELinux User   MLS/MCS Range    Service
   
   __default__   user_u         s0               *
   root          unconfined_u   s0-s0:c0.c1023   *

2. Vérifiez que les processus d'un nouvel utilisateur s'exécutent dans le contexte SELinux user_u:user_r:user_t:s0.

   1. Créer un nouvel utilisateur :

      # adduser example.user

   2. Définir un mot de passe pour example.user:

      # passwd example.user

   3. Déconnectez-vous en tant que root et connectez-vous en tant que nouvel utilisateur.

   4. Affiche le contexte de sécurité pour l'ID de l'utilisateur :

      [example.user@localhost ~]$ id -Z
      user_u:user_r:user_t:s0

   5. Affiche le contexte de sécurité des processus en cours de l'utilisateur :

      [example.user@localhost ~]$ ps axZ
      LABEL                           PID TTY      STAT   TIME COMMAND
      -                                 1 ?        Ss     0:05 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
      -                              3729 ?        S      0:00 (sd-pam)
      user_u:user_r:user_t:s0        3907 ?        Ss     0:00 /usr/lib/systemd/systemd --user
      -                              3911 ?        S      0:00 (sd-pam)
      user_u:user_r:user_t:s0        3918 ?        S      0:00 sshd: example.user@pts/0
      user_u:user_r:user_t:s0        3922 pts/0    Ss     0:00 -bash
      user_u:user_r:user_dbusd_t:s0  3969 ?        Ssl    0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
      user_u:user_r:user_t:s0        3971 pts/0    R+     0:00 ps axZ

Procédure

1. Facultatif : Pour permettre aux utilisateurs de sysadm_u de se connecter au système à l'aide de SSH :

   # setsebool -P ssh_sysadm_login on

2. Créez un nouvel utilisateur, ajoutez-le au groupe d'utilisateurs wheel et associez-le à l'utilisateur SELinux sysadm_u:

   # adduser -G wheel -Z sysadm_u example.user

3. Facultatif : Associez un utilisateur existant à l'utilisateur SELinux sysadm_u et ajoutez l'utilisateur au groupe d'utilisateurs wheel:

   # usermod -G wheel -Z sysadm_u example.user

Vérification

1. Vérifiez que example.user est associé à l'utilisateur SELinux sysadm_u:

   # semanage login -l | grep example.user
   example.user     sysadm_u    s0-s0:c0.c1023   *

2. Se connecter en tant que example.userpar exemple, en utilisant SSH, et afficher le contexte de sécurité de l'utilisateur :

   [example.user@localhost ~]$ id -Z
   sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

3. Passez à l'utilisateur root:

   $ sudo -i
   [sudo] password for example.user:

4. Vérifiez que le contexte de sécurité reste inchangé :

   # id -Z
   sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

5. Essayez une tâche administrative, par exemple en redémarrant le service sshd:

   # systemctl restart sshd

   S'il n'y a pas de sortie, la commande s'est terminée avec succès.

   Si la commande ne se termine pas avec succès, elle affiche le message suivant :

   Failed to restart sshd.service: Access denied
   See system logs and 'systemctl status sshd.service' for details.

Procédure

1. Créez un nouvel utilisateur, ajoutez-le au groupe d'utilisateurs wheel et associez-le à l'utilisateur SELinux staff_u:

   # adduser -G wheel -Z staff_u example.user

2. Facultatif : Associez un utilisateur existant à l'utilisateur SELinux staff_u et ajoutez l'utilisateur au groupe d'utilisateurs wheel:

   # usermod -G wheel -Z staff_u example.user

3. Pour permettre à example.user d'obtenir le rôle d'administrateur SELinux, créez un nouveau fichier dans le répertoire /etc/sudoers.d/, par exemple :

   # visudo -f /etc/sudoers.d/example.user

4. Ajoutez la ligne suivante au nouveau fichier :

   example.user ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r ALL

Vérification

1. Vérifiez que example.user est associé à l'utilisateur SELinux staff_u:

   # semanage login -l | grep example.user
   example.user     staff_u    s0-s0:c0.c1023   *

2. Connectez-vous en tant que example.user, par exemple en utilisant SSH, et passez à l'utilisateur root:

   [example.user@localhost ~]$ sudo -i
   [sudo] password for example.user:

3. Afficher le contexte de sécurité de root:

   # id -Z
   staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

4. Essayez une tâche administrative, par exemple en redémarrant le service sshd:

   # systemctl restart sshd

   S'il n'y a pas de sortie, la commande s'est terminée avec succès.

   Si la commande ne se termine pas avec succès, elle affiche le message suivant :

   Failed to restart sshd.service: Access denied
   See system logs and 'systemctl status sshd.service' for details.

Procédure

1. Démarrez le service httpd et vérifiez l'état :

   # systemctl start httpd
   # systemctl status httpd
   ...
   httpd[14523]: (13)Permission denied: AH00072: make_sock: could not bind to address [::]:3131
   ...
   systemd[1]: Failed to start The Apache HTTP Server.
   ...

2. La politique SELinux suppose que httpd fonctionne sur le port 80 :

   # semanage port -l | grep http
   http_cache_port_t              tcp      8080, 8118, 8123, 10001-10010
   http_cache_port_t              udp      3130
   http_port_t                    tcp      80, 81, 443, 488, 8008, 8009, 8443, 9000
   pegasus_http_port_t            tcp      5988
   pegasus_https_port_t           tcp      5989

3. Modifier le type SELinux du port 3131 pour qu'il corresponde au port 80 :

   # semanage port -a -t http_port_t -p tcp 3131

4. Recommencer httpd:

   # systemctl start httpd

5. Cependant, le contenu reste inaccessible :

   # wget localhost:3131/index.html
   ...
   HTTP request sent, awaiting response... 403 Forbidden
   ...

   Trouvez la raison à l'aide de l'outil sealert:

   # sealert -l "*"
   ...
   SELinux is preventing httpd from getattr access on the file /var/test_www/html/index.html.
   ...

6. Comparez les types SELinux pour le chemin standard et le nouveau chemin à l'aide de l'outil matchpathcon:

   # matchpathcon /var/www/html /var/test_www/html
   /var/www/html       system_u:object_r:httpd_sys_content_t:s0
   /var/test_www/html  system_u:object_r:var_t:s0

7. Modifiez le type SELinux du nouveau répertoire de contenu /var/test_www/html/ pour qu'il corresponde au type du répertoire par défaut /var/www/html:

   # semanage fcontext -a -e /var/www /var/test_www

8. Réétiqueter le répertoire /var de manière récursive :

   # restorecon -Rv /var/
   ...
   Relabeled /var/test_www/html from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:httpd_sys_content_t:s0
   Relabeled /var/test_www/html/index.html from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:httpd_sys_content_t:s0

Vérification

1. Vérifiez que le service httpd est en cours d'exécution :

   # systemctl status httpd
   ...
   Active: active (running)
   ...
   systemd[1]: Started The Apache HTTP Server.
   httpd[14888]: Server configured, listening on: port 3131
   ...

2. Vérifiez que le contenu fourni par le serveur HTTP Apache est accessible :

   # wget localhost:3131/index.html
   ...
   HTTP request sent, awaiting response... 200 OK
   Length: 0 [text/html]
   Saving to: ‘index.html’
   ...

Procédure

1. Identifier les booléens SELinux pertinents pour NFS, CIFS et Apache :

   # semanage boolean -l | grep 'nfs\|cifs' | grep httpd
   httpd_use_cifs                 (off  ,  off)  Allow httpd to access cifs file systems
   httpd_use_nfs                  (off  ,  off)  Allow httpd to access nfs file systems

2. Liste l'état actuel des booléens :

   $ getsebool -a | grep 'nfs\|cifs' | grep httpd
   httpd_use_cifs --> off
   httpd_use_nfs --> off

3. Activer les booléens identifiés :

   # setsebool httpd_use_nfs on
   # setsebool httpd_use_cifs on

   Note

   Utilisez la commande setsebool avec l'option -P pour que les modifications soient prises en compte lors des redémarrages. La commande setsebool -P nécessite une reconstruction de l'ensemble de la stratégie, ce qui peut prendre un certain temps en fonction de votre configuration.

Vérification

1. Vérifier que les booléens sont bien on:

   $ getsebool -a | grep 'nfs\|cifs' | grep httpd
   httpd_use_cifs --> on
   httpd_use_nfs --> on

Procédure

1. Lorsque votre scénario est bloqué par SELinux, le fichier /var/log/audit/audit.log est le premier endroit à consulter pour obtenir plus d'informations sur un refus. Pour interroger les journaux d'audit, utilisez l'outil ausearch. Étant donné que les décisions de SELinux, telles que l'autorisation ou le refus d'accès, sont mises en cache et que ce cache est connu sous le nom d'Access Vector Cache (AVC), utilisez les valeurs AVC et USER_AVC pour le paramètre de type de message, par exemple :

   # ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent

   S'il n'y a pas de correspondance, vérifiez si le démon d'audit est en cours d'exécution. Si ce n'est pas le cas, répétez le scénario refusé après avoir démarré auditd et vérifiez à nouveau le journal d'audit.

2. Si auditd est en cours d'exécution, mais qu'il n'y a pas de correspondance dans la sortie de ausearch, vérifiez les messages fournis par le journal systemd:

   # journalctl -t setroubleshoot

3. Si SELinux est actif et que le démon d'audit ne fonctionne pas sur votre système, recherchez certains messages SELinux dans la sortie de la commande dmesg:

   # dmesg | grep -i -e type=1300 -e type=1400

4. Même après les trois contrôles précédents, il est encore possible que vous n'ayez rien trouvé. Dans ce cas, les refus de l'AVC peuvent être réduits au silence grâce aux règles du site dontaudit.

   Pour désactiver temporairement les règles dontaudit, ce qui permet d'enregistrer tous les refus :

   # semodule -DB

   Après avoir réexécuté votre scénario de refus et trouvé des messages de refus à l'aide des étapes précédentes, la commande suivante active à nouveau les règles dontaudit dans la stratégie :

   # semodule -B

5. Si vous appliquez les quatre étapes précédentes et que le problème n'est toujours pas identifié, demandez-vous si SELinux bloque réellement votre scénario :

   • Passer en mode permissif :

     # setenforce 0
     $ getenforce
     Permissive

   • Répétez votre scénario.

   Si le problème persiste, c'est que quelque chose d'autre que SELinux bloque votre scénario.

Procédure

1. Lister plus de détails sur un refus enregistré à l'aide de la commande sealert, par exemple :

   $ sealert -l "*"
   SELinux is preventing /usr/bin/passwd from write access on the file
   /root/test.
   
   *****  Plugin leaks (86.2 confidence) suggests *****************************
   
   If you want to ignore passwd trying to write access the test file,
   because you believe it should not need this access.
   Then you should report this as a bug.
   You can generate a local policy module to dontaudit this access.
   Do
   # ausearch -x /usr/bin/passwd --raw | audit2allow -D -M my-passwd
   # semodule -X 300 -i my-passwd.pp
   
   *****  Plugin catchall (14.7 confidence) suggests **************************
   
   ...
   
   Raw Audit Messages
   type=AVC msg=audit(1553609555.619:127): avc:  denied  { write } for
   pid=4097 comm="passwd" path="/root/test" dev="dm-0" ino=17142697
   scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023
   tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0
   
   ...
   
   Hash: passwd,passwd_t,admin_home_t,file,write

2. Si les résultats obtenus à l'étape précédente ne contiennent pas de suggestions claires :

   • Activez l'audit du chemin complet pour voir les chemins d'accès complets aux objets accédés et pour rendre visibles des champs supplémentaires de l'événement Linux Audit :

     # auditctl -w /etc/shadow -p w -k shadow-write

   • Vider le cache de setroubleshoot:

     # rm -f /var/lib/setroubleshoot/setroubleshoot.xml

   • Reproduire le problème.

   • Répéter l'étape 1.

     Une fois la procédure terminée, désactivez l'audit du chemin complet :

     # auditctl -W /etc/shadow -p w -k shadow-write

3. Si sealert ne renvoie que des suggestions catchall ou suggère d'ajouter une nouvelle règle à l'aide de l'outil audit2allow, comparez votre problème aux exemples répertoriés et expliqués dans SELinux denials (refus d'autorisation SELinux) dans le journal d'audit.

Procédure

1. Installez le paquetage selinux-policy-mls:

   # dnf install selinux-policy-mls

2. Ouvrez le fichier /etc/selinux/config dans un éditeur de texte de votre choix, par exemple :

   # vi /etc/selinux/config

3. Changez le mode SELinux de "enforcing" à "permissive" et passez de la politique ciblée à la politique MLS :

   SELINUX=permissive
   SELINUXTYPE=mls

   Enregistrez les modifications et quittez l'éditeur.

4. Avant d'activer la stratégie MLS, vous devez attribuer une étiquette MLS à chaque fichier du système de fichiers :

   # fixfiles -F onboot
   System will relabel on next boot

5. Redémarrer le système :

   # reboot

6. Vérifier les refus SELinux :

   # ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent -i

   La commande précédente ne couvrant pas tous les cas de figure, reportez-vous à la section Dépannage des problèmes liés à SEL inux pour obtenir des conseils sur l'identification, l'analyse et la résolution des refus SELinux.

7. Après vous être assuré qu'il n'y a pas de problèmes liés à SELinux sur votre système, remettez SELinux en mode "enforcing" en modifiant l'option correspondante dans /etc/selinux/config:

   SELINUX=enforcing

8. Redémarrer le système :

   # reboot

Vérification

1. Vérifiez que SELinux fonctionne en mode d'exécution :

   # getenforce
   Enforcing

2. Vérifiez que le statut de SELinux renvoie la valeur mls:

   # sestatus | grep mls
   Loaded policy name:             mls

Procédure

1. Facultatif : Pour éviter d'ajouter des erreurs à votre politique SELinux, passez au mode SELinux permissive, qui facilite le dépannage :

   # setenforce 0

   Important

   En mode permissif, SELinux n'applique pas la politique active mais enregistre uniquement les messages AVC (Access Vector Cache), qui peuvent ensuite être utilisés à des fins de dépannage et de débogage.

2. Définir une plage d'autorisation pour l'utilisateur SELinux staff_u. Par exemple, cette commande définit la plage d'autorisation de s1 à s15, s1 étant le niveau d'autorisation par défaut :

   # semanage user -m -L s1 -r s1-s15 _staff_u

3. Génère des entrées de configuration du contexte de fichier SELinux pour les répertoires personnels des utilisateurs :

   # genhomedircon

4. Rétablir les contextes de sécurité des fichiers par défaut :

   # restorecon -R -F -v /home/
   Relabeled /home/staff from staff_u:object_r:user_home_dir_t:s0 to staff_u:object_r:user_home_dir_t:s1
   Relabeled /home/staff/.bash_logout from staff_u:object_r:user_home_t:s0 to staff_u:object_r:user_home_t:s1
   Relabeled /home/staff/.bash_profile from staff_u:object_r:user_home_t:s0 to staff_u:object_r:user_home_t:s1
   Relabeled /home/staff/.bashrc from staff_u:object_r:user_home_t:s0 to staff_u:object_r:user_home_t:s1

5. Attribuer un niveau d'autorisation à l'utilisateur :

   # semanage login -m -r s1 example_user

   Où s1 est le niveau d'habilitation attribué à l'utilisateur.

6. Adapter le répertoire personnel de l'utilisateur au niveau d'autorisation de l'utilisateur :

   # chcon -R -l s1 /home/example_user

7. Facultatif : si vous êtes passé au mode SELinux permissive, et après avoir vérifié que tout fonctionne comme prévu, repassez au mode SELinux enforcing:

   # setenforce 1

Verification steps

1. Vérifiez que l'utilisateur est associé au bon utilisateur SELinux et que le niveau d'autorisation attribué est correct :

   # semanage login -l
   Login Name      SELinux User         MLS/MCS Range        Service
   __default__     user_u               s0-s0                *
   example_user    user_u               s1                   *
   ...

2. Connectez-vous en tant qu'utilisateur dans MLS.

3. Vérifiez que le niveau de sécurité de l'utilisateur fonctionne correctement :

   Important

   Les fichiers utilisés pour la vérification ne doivent pas contenir d'informations sensibles, au cas où la configuration serait incorrecte et où l'utilisateur pourrait accéder aux fichiers sans autorisation.

   1. Vérifiez que l'utilisateur ne peut pas lire un fichier dont le niveau de sensibilité est plus élevé.
   2. Vérifiez que l'utilisateur peut écrire dans un fichier avec la même sensibilité.
   3. Vérifiez que l'utilisateur peut lire un fichier dont le niveau de sensibilité est inférieur.

Procédure

1. Se connecter en tant qu'utilisateur à partir d'un terminal sécurisé.

   Note

   Les terminaux sécurisés sont définis dans le fichier /etc/selinux/mls/contexts/securetty_types. Par défaut, la console est un terminal sécurisé, mais pas SSH.

2. Vérifier le contexte de sécurité de l'utilisateur actuel :

   $ id -Z
   user_u:user_r:user_t:s0-s2

   Dans cet exemple, l'utilisateur est affecté à l'utilisateur SELinux user_u, au rôle user_r, au type user_t et à la plage de sécurité MLS s0-s2.

3. Vérifier le contexte de sécurité de l'utilisateur actuel :

   $ id -Z
   user_u:user_r:user_t:s1-s2

4. Passer à une autre plage d'habilitation de sécurité dans la plage d'habilitation de l'utilisateur :

   $ newrole -l s1

   Vous pouvez passer à n'importe quelle plage dont le maximum est inférieur ou égal à la plage qui vous a été attribuée. La saisie d'une plage à niveau unique modifie la limite inférieure de la plage attribuée. Par exemple, la saisie de newrole -l s1 en tant qu'utilisateur ayant une plage s0-s2 équivaut à la saisie de newrole -l s1-s2.

Vérification

1. Affiche le contexte de sécurité de l'utilisateur actuel :

   $ id -Z
   user_u:user_r:user_t:s1-s2

2. Retourner à l'interpréteur de commandes précédent avec la portée originale en mettant fin à l'interpréteur de commandes actuel :

   $ exit

Procédure

1. Facultatif : Affiche le contexte de sécurité de l'utilisateur actuel :

   $ id -Z
   user_u:user_r:user_t:s0-s2

2. Modifiez le niveau inférieur de l'habilitation MLS de l'utilisateur pour qu'il corresponde au niveau que vous souhaitez attribuer au dossier :

   $ newrole -l s1-s2

3. Facultatif : Affiche le contexte de sécurité de l'utilisateur actuel :

   $ id -Z
   user_u:user_r:user_t:s1-s2

4. Facultatif : Afficher le contexte de sécurité du fichier :

   $ ls -Z /path/to/file
   user_u:object_r:user_home_t:s0 /path/to/file

5. Modifier le niveau de sensibilité du fichier pour qu'il corresponde au niveau le plus bas de l'habilitation de l'utilisateur en modifiant le fichier :

   $ touch /path/to/file

   Important

   Le niveau de classification reprend sa valeur par défaut si la commande restorecon est utilisée sur le système.

6. Facultatif : Quitter le shell pour revenir à la plage de sécurité précédente de l'utilisateur :

   $ exit

Procédure

1. Vérifier le niveau de classification du fichier :

   # ls -lZ /path/to/file
   -rw-r-----. 1 User1 User1 user_u:object_r:user_home_t:s1 0 12. Feb 10:43 /path/to/file

2. Modifier le niveau de classification par défaut du fichier :

   # semanage fcontext -a -r s2 /path/to/file

3. Force le changement d'étiquette du contexte SELinux du fichier :

   # restorecon -F -v /path/to/file
   Relabeled /path/to/file from user_u:object_r:user_home_t:s1 to user_u:object_r:user_home_t:s2

Vérification

1. Vérifier le niveau de classification du fichier :

   # ls -lZ /path/to/file
   -rw-r-----. 1 User1 User1 user_u:object_r:user_home_t:s2 0 12. Feb 10:53 /path/to/file

2. Facultatif : Vérifiez que l'utilisateur ayant un niveau d'habilitation inférieur ne peut pas lire le fichier :

   $ cat /path/to/file
   cat: file: Permission denied

Procédure

1. Créez un nouveau fichier sudoers dans le répertoire /etc/sudoers.d pour l'utilisateur :

   # visudo -f /etc/sudoers.d/<sec_adm_user>

   Pour que les fichiers sudoers restent organisés, remplacez <sec_adm_user> par l'utilisateur Linux auquel sera attribué le rôle secadm.

2. Ajoutez le contenu suivant dans le fichier /etc/sudoers.d/<sec_adm_user> le contenu suivant :

   <sec_adm_user> ALL=(ALL) TYPE=secadm_t ROLE=secadm_r ALL

   Cette ligne autorise <secadmuser> sur tous les hôtes à exécuter toutes les commandes, et attribue à l'utilisateur le type et le rôle SELinux secadm par défaut.

3. Connectez-vous en tant qu'utilisateur de <sec_adm_user>:

   Note

   Pour s'assurer que le contexte SELinux (qui comprend l'utilisateur SELinux, le rôle et le type) est modifié, connectez-vous en utilisant ssh, la console ou xdm. Les autres moyens, tels que su et sudo, ne peuvent pas modifier l'ensemble du contexte SELinux.

4. Vérifier le contexte de sécurité de l'utilisateur :

   $ id
   uid=1000(<sec_adm_user>) gid=1000(<sec_adm_user>) groups=1000(<sec_adm_user>) context=staff_u:staff_r:staff_t:s0-s15:c0.c1023

5. Exécute l'interpréteur de commandes interactif pour l'utilisateur root :

   $ sudo -i
   [sudo] password for <sec_adm_user>:

6. Vérifier le contexte de sécurité de l'utilisateur actuel :

   # id
   uid=0(root) gid=0(root) groups=0(root) context=staff_u:secadm_r:secadm_t:s0-s15:c0.c1023

7. Désactiver le module sysadm_secadm de la politique :

   # semodule -d sysadm_secadm

   Important

   Utilisez la commande semodule -d au lieu de supprimer le module de politique du système à l'aide de la commande semodule -r. La commande semodule -r supprime le module du stockage de votre système, ce qui signifie qu'il ne peut pas être chargé à nouveau sans réinstaller le paquetage selinux-policy-mls.

Vérification

1. En tant qu'utilisateur assigné au rôle secadm et dans le shell interactif de l'utilisateur root, vérifiez que vous pouvez accéder aux données de la politique de sécurité :

   # seinfo -xt secadm_t
   
   Types: 1
      type secadm_t, can_relabelto_shadow_passwords, (...) userdomain;

2. Se déconnecter de l'interpréteur de commandes racine :

   # logout

3. Se déconnecter de l'utilisateur <sec_adm_user> l'utilisateur :

   $ logout
   Connection to localhost closed.

4. Affiche le contexte de sécurité actuel :

   # id
   uid=0(root) gid=0(root) groups=0(root) context=root:sysadm_r:sysadm_t:s0-s15:c0.c1023

5. Tentative d'activation du module sysadm_secadm. La commande devrait échouer :

   # semodule -e sysadm_secadm
   SELinux:  Could not load policy file /etc/selinux/mls/policy/policy.31:  Permission denied
   /sbin/load_policy:  Can't load policy:  Permission denied
   libsemanage.semanage_reload_policy: load_policy returned error code 2. (No such file or directory).
   SELinux:  Could not load policy file /etc/selinux/mls/policy/policy.31:  Permission denied
   /sbin/load_policy:  Can't load policy:  Permission denied
   libsemanage.semanage_reload_policy: load_policy returned error code 2. (No such file or directory).
   semodule:  Failed!

6. Tentative d'affichage des détails concernant le type SELinux sysadm_t. La commande doit échouer :

   # seinfo -xt sysadm_t
   [Errno 13] Permission denied: '/sys/fs/selinux/policy'

Procédure

1. Déterminer le type de borne de courant :

   # ls -Z `tty`
   root:object_r:user_devpts_t:s0 /dev/pts/0

   Dans cet exemple, user_devpts_t est le type de terminal actuel.

2. Ajoutez le type SELinux approprié sur une nouvelle ligne du fichier /etc/selinux/mls/contexts/securetty_types.

3. Optionnel : Passer SELinux en mode d'application :

   # setenforce 1

Procédure

1. En option : Passer en mode permissif pour faciliter le dépannage.

   # setenforce 0

2. Ouvrez un nouveau fichier .cil avec un éditeur de texte, par exemple ~/local_mlsfilewrite.cil, et insérez la règle personnalisée suivante :

   (typeattributeset mlsfilewrite (_staff_t_))

   Vous pouvez remplacer staff_t par un type SELinux différent. En spécifiant le type SELinux ici, vous pouvez contrôler quels rôles SELinux peuvent éditer des fichiers de niveau inférieur.

   Pour mieux organiser vos modules locaux, utilisez le préfixe local_ dans les noms des modules de politique SELinux locaux.

3. Installer le module de politique :

   # semodule -i ~/local_mlsfilewrite.cil

   Note

   Pour supprimer le module de politique locale, utilisez semodule -r ~/local_mlsfilewrite. Notez que vous devez vous référer au nom du module sans le suffixe .cil.

4. Facultatif : si vous avez précédemment rétabli le mode permissif, revenez au mode exécutoire :

   # setenforce 1

Vérification

1. Trouver le module local dans la liste des modules SELinux installés :

   # semodule -lfull | grep "local_mls"
   400 local_mlsfilewrite  cil

   Comme les modules locaux ont la priorité 400, vous pouvez également les lister en utilisant la commande semodule -lfull | grep -v ^100.

2. Se connecter en tant qu'utilisateur assigné au type défini dans la règle personnalisée, par exemple, staff_t.

3. Tenter d'écrire dans un fichier dont le niveau de sensibilité est inférieur. Le niveau de classification du fichier est alors porté au niveau d'habilitation de l'utilisateur.

   Important

   Les fichiers utilisés pour la vérification ne doivent pas contenir d'informations sensibles, au cas où la configuration serait incorrecte et où l'utilisateur pourrait accéder aux fichiers sans autorisation.

Procédure

1. Créez un nouveau fichier nommé, par exemple, local_mcs_user.cil:

   # vim local_mcs_user.cil

2. Insérer la règle suivante :

   (typeattributeset mcs_constrained_type (user_t))

3. Installer le module de politique :

   # semodule -i local_mcs_user.cil

Procédure

1. Modifiez les catégories existantes ou créez-en de nouvelles en éditant le fichier /etc/selinux/<selinuxpolicy>/setrans.conf dans un éditeur de texte. Remplacez <selinuxpolicy> par targeted ou mls en fonction de la politique SELinux que vous utilisez. Par exemple :

   # vi /etc/selinux/targeted/setrans.conf

2. Dans le fichier setrans.conf de votre police, définissez les combinaisons de catégories requises par votre scénario à l'aide de la syntaxe suivante s_<security level>_:c_<category number>_=<category.name>par exemple :

   s0:c0=Marketing
   s0:c1=Finance
   s0:c2=Payroll
   s0:c3=Personnel

   • Vous pouvez utiliser les numéros de catégorie de c0 à c1023.
   • Dans la politique targeted, utilisez le niveau de sécurité s0.
   • Dans la politique mls, vous pouvez étiqueter chaque combinaison de niveaux de sensibilité et de catégories.
3. Facultatif : dans le fichier setrans.conf, vous pouvez également étiqueter les niveaux de sensibilité MLS.
4. Save and exit the file.

5. Pour que les modifications soient effectives, redémarrez le service de traduction MCS :

   # systemctl restart mcstrans

Procédure

1. Définir la plage de sécurité pour l'utilisateur SELinux.

   # semanage user -m -rs0:c0,c1-s0:c0.c9 <user_u>

   Utilisez les numéros de catégorie c0 à c1023 ou les étiquettes de catégorie définies dans le fichier setrans.conf. Pour plus d'informations, voir Définir des étiquettes de catégorie dans MCS.

2. Attribuer des catégories MCS à un utilisateur Linux. Vous ne pouvez spécifier qu'une plage à l'intérieur de la plage définie pour l'utilisateur SELinux concerné :

   # semanage login -m -rs0:c1 <Linux.user1>

   Note

   Vous pouvez ajouter ou supprimer des catégories d'utilisateurs Linux à l'aide de la commande chcat. L'exemple suivant ajoute <category1> et supprime <category2> de <Linux.user1> et <Linux.user2>:

   # chcat -l -- <category1>,-<category2> <Linux.user1>,<Linux.user2>

   Notez que vous devez spécifier -- sur la ligne de commande avant d'utiliser la syntaxe -<category> avant d'utiliser la syntaxe. Sinon, la commande chcat interprète mal la suppression de la catégorie comme une option de commande.

Vérification

1. Affichez le contexte de sécurité du fichier pour vérifier qu'il possède les catégories correctes :

   $ ls -lZ <path/to/file>
   -rw-r--r--  <LinuxUser1> <Group1> root:object_r:user_home_t:_<sensitivity>_:_<category>_ <path/to/file>

   Le contexte de sécurité spécifique du fichier peut être différent.

2. Facultatif : Tenter d'accéder au fichier en étant connecté en tant qu'utilisateur Linux n'appartenant pas à la même catégorie que le fichier :

   $ cat <path/to/file>
   cat: <path/to/file>: Permission Denied

Procédure

1. Pour cet exemple de procédure, préparez un simple démon qui ouvre le fichier /var/log/messages en écriture :

   1. Créez un nouveau fichier et ouvrez-le dans l'éditeur de texte de votre choix :

      $ vi mydaemon.c

   2. Insérer le code suivant :

      #include <unistd.h>
      #include <stdio.h>
      
      FILE *f;
      
      int main(void)
      {
      while(1) {
      f = fopen("/var/log/messages","w");
              sleep(5);
              fclose(f);
          }
      }

   3. Compiler le fichier :

      $ gcc -o mydaemon mydaemon.c

   4. Créez un fichier d'unité systemd pour votre démon :

      $ vi mydaemon.service
      [Unit]
      Description=Simple testing daemon
      
      [Service]
      Type=simple
      ExecStart=/usr/local/bin/mydaemon
      
      [Install]
      WantedBy=multi-user.target

   5. Installer et démarrer le démon :

      # cp mydaemon /usr/local/bin/
      # cp mydaemon.service /usr/lib/systemd/system
      # systemctl start mydaemon
      # systemctl status mydaemon
      ● mydaemon.service - Simple testing daemon
         Loaded: loaded (/usr/lib/systemd/system/mydaemon.service; disabled; vendor preset: disabled)
         Active: active (running) since Sat 2020-05-23 16:56:01 CEST; 19s ago
       Main PID: 4117 (mydaemon)
          Tasks: 1
         Memory: 148.0K
         CGroup: /system.slice/mydaemon.service
                 └─4117 /usr/local/bin/mydaemon
      
      May 23 16:56:01 localhost.localdomain systemd[1]: Started Simple testing daemon.

   6. Vérifiez que le nouveau démon n'est pas limité par SELinux :

      $ ps -efZ | grep mydaemon
      system_u:system_r:unconfined_service_t:s0 root 4117    1  0 16:56 ?        00:00:00 /usr/local/bin/mydaemon

2. Générer une politique personnalisée pour le démon :

   $ sepolicy generate --init /usr/local/bin/mydaemon
   Created the following files:
   /home/example.user/mysepol/mydaemon.te # Type Enforcement file
   /home/example.user/mysepol/mydaemon.if # Interface file
   /home/example.user/mysepol/mydaemon.fc # File Contexts file
   /home/example.user/mysepol/mydaemon_selinux.spec # Spec file
   /home/example.user/mysepol/mydaemon.sh # Setup Script

3. Reconstruire la politique du système avec le nouveau module de politique en utilisant le script d'installation créé par la commande précédente :

   # ./mydaemon.sh
   Building and Loading Policy
   + make -f /usr/share/selinux/devel/Makefile mydaemon.pp
   Compiling targeted mydaemon module
   Creating targeted mydaemon.pp policy package
   rm tmp/mydaemon.mod.fc tmp/mydaemon.mod
   + /usr/sbin/semodule -i mydaemon.pp
   ...

   Notez que le script d'installation renomme la partie correspondante du système de fichiers à l'aide de la commande restorecon:

   restorecon -v /usr/local/bin/mydaemon /usr/lib/systemd/system

4. Redémarrez le démon et vérifiez qu'il fonctionne désormais dans le respect de SELinux :

   # systemctl restart mydaemon
   $ ps -efZ | grep mydaemon
   system_u:system_r:mydaemon_t:s0 root        8150       1  0 17:18 ?        00:00:00 /usr/local/bin/mydaemon

5. Étant donné que le démon est désormais confiné par SELinux, SELinux l'empêche également d'accéder à /var/log/messages. Affichez le message de refus correspondant :

   # ausearch -m AVC -ts recent
   ...
   type=AVC msg=audit(1590247112.719:5935): avc:  denied  { open } for  pid=8150 comm="mydaemon" path="/var/log/messages" dev="dm-0" ino=2430831 scontext=system_u:system_r:mydaemon_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file permissive=1
   ...

6. Vous pouvez également obtenir des informations supplémentaires en utilisant l'outil sealert:

   $ sealert -l "*"
   SELinux is preventing mydaemon from open access on the file /var/log/messages.
   
    Plugin catchall (100. confidence) suggests *
   
   If you believe that mydaemon should be allowed open access on the messages file by default.
   Then you should report this as a bug.
   You can generate a local policy module to allow this access.
   Do
   allow this access for now by executing:
   # ausearch -c 'mydaemon' --raw | audit2allow -M my-mydaemon
   # semodule -X 300 -i my-mydaemon.pp
   
   Additional Information:
   Source Context                system_u:system_r:mydaemon_t:s0
   Target Context                unconfined_u:object_r:var_log_t:s0
   Target Objects                /var/log/messages [ file ]
   Source                        mydaemon
   
   ...

7. Utilisez l'outil audit2allow pour suggérer des changements :

   $ ausearch -m AVC -ts recent | audit2allow -R
   
   require {
   	type mydaemon_t;
   }
   
   #============= mydaemon_t ==============
   logging_write_generic_logs(mydaemon_t)

8. Les règles suggérées par audit2allow pouvant être incorrectes dans certains cas, n'utilisez qu'une partie de ses résultats pour trouver l'interface de politique correspondante :

   $ grep -r "logging_write_generic_logs" /usr/share/selinux/devel/include/ | grep .if
   /usr/share/selinux/devel/include/system/logging.if:interface(`logging_write_generic_logs',`

9. Vérifier la définition de l'interface :

   $ cat /usr/share/selinux/devel/include/system/logging.if
   ...
   interface(`logging_write_generic_logs',`
           gen_require(`
                   type var_log_t;
           ')
   
           files_search_var($1)
           allow $1 var_log_t:dir list_dir_perms;
           write_files_pattern($1, var_log_t, var_log_t)
   ')
   ...

10. Dans ce cas, vous pouvez utiliser l'interface proposée. Ajoutez la règle correspondante à votre fichier d'application des types :

    $ echo "logging_write_generic_logs(mydaemon_t)" >> mydaemon.te

    Vous pouvez également ajouter cette règle au lieu d'utiliser l'interface :

    $ echo "allow mydaemon_t var_log_t:file { open write getattr };" >> mydaemon.te

11. Réinstaller la politique :

    # ./mydaemon.sh
    Building and Loading Policy
    + make -f /usr/share/selinux/devel/Makefile mydaemon.pp
    Compiling targeted mydaemon module
    Creating targeted mydaemon.pp policy package
    rm tmp/mydaemon.mod.fc tmp/mydaemon.mod
    + /usr/sbin/semodule -i mydaemon.pp
    ...

Vérification

1. Vérifiez que votre application fonctionne dans le cadre de SELinux, par exemple :

   $ ps -efZ | grep mydaemon
   system_u:system_r:mydaemon_t:s0 root        8150       1  0 17:18 ?        00:00:00 /usr/local/bin/mydaemon

2. Vérifiez que votre application personnalisée ne provoque pas de refus SELinux :

   # ausearch -m AVC -ts recent
   <no matches>

Procédure

1. Ouvrez un nouveau fichier .cil avec un éditeur de texte, par exemple :

   # vim <local_module>.cil

   Pour mieux organiser vos modules locaux, utilisez le préfixe local_ dans les noms des modules de politique SELinux locaux.

2. Insérez les règles personnalisées à partir d'un problème connu ou d'une solution Red Hat.

   Important

   N'écrivez pas vos propres règles. Utilisez uniquement les règles fournies dans un problème connu spécifique ou une solution Red Hat.

   Par exemple, pour mettre en œuvre la solution SELinux denies cups-lpd read access to cups.sock in RHEL, insérez la règle suivante :

   Note

   L'exemple de solution a été corrigé de manière permanente pour RHEL dans RHBA-2021:4420. Par conséquent, les parties de cette procédure spécifiques à cette solution n'ont aucun effet sur les systèmes RHEL 8 et 9 mis à jour, et ne sont incluses qu'à titre d'exemples de syntaxe.

   (allow cupsd_lpd_t cupsd_var_run_t (sock_file (read)))

   Notez que vous pouvez utiliser l'une ou l'autre des deux syntaxes de règles SELinux, Common Intermediate Language (CIL) et m4. Par exemple, (allow cupsd_lpd_t cupsd_var_run_t (sock_file (read))) en CIL est équivalent à ce qui suit en m4 :

   module local_cupslpd-read-cupssock 1.0;
   
   require {
       type cupsd_var_run_t;
       type cupsd_lpd_t;
       class sock_file read;
   }
   
   #============= cupsd_lpd_t ==============
   allow cupsd_lpd_t cupsd_var_run_t:sock_file read;

3. Enregistrez et fermez le fichier.

4. Installer le module de politique :

   # semodule -i <local_module>.cil

   Note

   Pour supprimer un module de politique locale créé à l'aide de semodule -i, il convient de se référer au nom du module sans le suffixe .cil. Pour supprimer un module de politique locale, utilisez semodule -r <local_module>.

5. Redémarrer tous les services liés aux règles :

   # systemctl restart <service-name>

Vérification

1. Liste des modules locaux installés dans votre politique SELinux :

   # semodule -lfull | grep "local_"
   400 local_module  cil

   Note

   Les modules locaux ayant la priorité 400, vous pouvez également les filtrer de la liste en utilisant cette valeur, par exemple en utilisant la commande semodule -lfull | grep -v ^100.

2. Recherchez les règles d'autorisation pertinentes dans la politique SELinux :

   # sesearch -A --source=<SOURCENAME> --target=<TARGETNAME> --class=<CLASSNAME> --perm=<P1>,<P2>

   Où <SOURCENAME> est le type SELinux source, <TARGETNAME> est le type SELinux cible, <CLASSNAME> est le nom de la classe de sécurité ou de la classe d'objets, et <P1> et <P2> sont les autorisations spécifiques de la règle.

   Par exemple, pour la solution RHEL, SELinux refuse à cups-lpd l'accès en lecture à cups.sock :

   # sesearch -A --source=cupsd_lpd_t --target=cupsd_var_run_t --class=sock_file --perm=read
   allow cupsd_lpd_t cupsd_var_run_t:sock_file { append getattr open read write };

   La dernière ligne doit maintenant inclure l'opération read.

3. Vérifiez que le service concerné fonctionne dans le cadre de SELinux :

   1. Identifier le processus lié au service concerné :

      $ systemctl status <service-name>

   2. Vérifiez le contexte SELinux du processus répertorié dans la sortie de la commande précédente :

      $ ps -efZ | grep <process-name>

4. Vérifier que le service ne provoque pas de déni SELinux :

   # ausearch -m AVC -ts recent
   <no matches>

1. Analyse du fichier de spécification du conteneur au format JSON
2. Trouver des règles d'autorisation appropriées sur la base des résultats de la première partie
3. Génération de la politique SELinux finale

Procédure

1. Installez le paquetage udica:

   # dnf install -y udica

   Vous pouvez également installer le module container-tools, qui fournit un ensemble de logiciels de conteneurs, dont udica:

   # dnf module install -y container-tools

2. Démarrez le conteneur ubi8 qui monte le répertoire /home avec des autorisations de lecture seule et le répertoire /var/spool avec des autorisations de lecture et d'écriture. Le conteneur expose le port 21.

   # podman run --env container=podman -v /home:/home:ro -v /var/spool:/var/spool:rw -p 21:21 -it ubi8 bash

   Notez que le conteneur fonctionne maintenant avec le type SELinux container_t. Ce type est un domaine générique pour tous les conteneurs dans la politique SELinux et il peut être trop strict ou trop lâche pour votre scénario.

3. Ouvrez un nouveau terminal et entrez la commande podman ps pour obtenir l'ID du conteneur :

   # podman ps
   CONTAINER ID   IMAGE                                   COMMAND   CREATED          STATUS              PORTS   NAMES
   37a3635afb8f   registry.access.redhat.com/ubi8:latest  bash      15 minutes ago   Up 15 minutes ago           heuristic_lewin

4. Créez un fichier JSON de conteneur et utilisez udica pour créer un module de politique basé sur les informations contenues dans le fichier JSON :

   # podman inspect 37a3635afb8f > container.json
   # udica -j container.json my_container
   Policy my_container with container id 37a3635afb8f created!
   [...]

   Alternativement :

   # podman inspect 37a3635afb8f | udica my_container
   Policy my_container with container id 37a3635afb8f created!
   
   Please load these modules using:
   # semodule -i my_container.cil /usr/share/udica/templates/{base_container.cil,net_container.cil,home_container.cil}
   
   Restart the container with: "--security-opt label=type:my_container.process" parameter

5. Comme le suggère la sortie de udica à l'étape précédente, chargez le module de politique :

   # semodule -i my_container.cil /usr/share/udica/templates/{base_container.cil,net_container.cil,home_container.cil}

6. Arrêtez le conteneur et redémarrez-le avec l'option --security-opt label=type:my_container.process:

   # podman stop 37a3635afb8f
   # podman run --security-opt label=type:my_container.process -v /home:/home:ro -v /var/spool:/var/spool:rw -p 21:21 -it ubi8 bash

Vérification

1. Vérifiez que le conteneur fonctionne avec le type my_container.process:

   # ps -efZ | grep my_container.process
   unconfined_u:system_r:container_runtime_t:s0-s0:c0.c1023 root 2275 434  1 13:49 pts/1 00:00:00 podman run --security-opt label=type:my_container.process -v /home:/home:ro -v /var/spool:/var/spool:rw -p 21:21 -it ubi8 bash
   system_u:system_r:my_container.process:s0:c270,c963 root 2317 2305  0 13:49 pts/0 00:00:00 bash

2. Vérifiez que SELinux autorise désormais l'accès aux points de montage /home et /var/spool:

   [root@37a3635afb8f /]# cd /home
   [root@37a3635afb8f home]# ls
   username
   [root@37a3635afb8f ~]# cd /var/spool/
   [root@37a3635afb8f spool]# touch test
   [root@37a3635afb8f spool]#

3. Vérifiez que SELinux n'autorise que la connexion au port 21 :

   [root@37a3635afb8f /]# dnf install nmap-ncat
   [root@37a3635afb8f /]# nc -lvp 21
   ...
   Ncat: Listening on :::21
   Ncat: Listening on 0.0.0.0:21
   ^C
   [root@37a3635afb8f /]# nc -lvp 80
   ...
   Ncat: bind to :::80: Permission denied. QUITTING.

Procédure

1. Préparez votre playbook. Vous pouvez partir de zéro ou modifier le playbook d'exemple installé avec le paquetage rhel-system-roles:

   # cp /usr/share/doc/rhel-system-roles/selinux/example-selinux-playbook.yml my-selinux-playbook.yml
   # vi my-selinux-playbook.yml

2. Modifiez le contenu du playbook pour l'adapter à votre scénario. Par exemple, la partie suivante garantit que le système installe et active le module SELinux selinux-local-1.pp:

   selinux_modules:
   - { path: "selinux-local-1.pp", priority: "400" }

3. Enregistrez les modifications et quittez l'éditeur de texte.

4. Exécutez votre manuel de jeu sur les systèmes host1, host2 et host3:

   # ansible-playbook -i host1,host2,host3 my-selinux-playbook.yml

Procédure

1. Exportez vos paramètres SELinux vérifiés :

   # semanage export -f ./my-selinux-settings.mod

2. Copiez le fichier contenant les paramètres sur le nouveau système :

   # scp ./my-selinux-settings.mod new-system-hostname:

3. Se connecter au nouveau système :

   $ ssh root@new-system-hostname

4. Importer les paramètres sur le nouveau système :

   new-system-hostname# semanage import -f ./my-selinux-settings.mod