Accéder au contenuNavigation Accéder à la page : page précédente [raccourci clavier p] / page suivante [raccourci clavier n]
documentation.suse.com / Dépannage de SELinux

Dépannage de SELinux

Date de publication : 18 jun 2025
CONTENU

Un système exécutant SELinux en mode enforcing peut provoquer des refus d'accès risquant d'empêcher l'exécution correcte des applications. Vous pouvez utiliser audit2allow ou setroubleshoot pour faciliter l'analyse des messages de refus.

MOTIF

Cet article donne des instructions expliquant comment résoudre les refus d'accès causés par SELinux sans compromettre la sécurité de votre système.

EFFORT

La lecture de l'article prend environ 30 minutes.

OBJECTIF

Vous pourrez utiliser l'un des outils décrits plus en détail ci-après pour déboguer les refus SELinux.

CONDITIONS REQUISES

  • Un système en cours d'exécution avec SELinux activé.

1 Fichier /var/log/audit/audit.log

 

Par défaut, si SELinux est à l'origine d'un quelconque problème de fonctionnement, un message est consigné dans le fichier journal /var/log/audit/audit.log.

Note
Note : fichier /var/log/audit/audit.log vide

Si le journal /var/log/audit/audit.log est vide, cela signifie généralement que le service auditd n'est pas en cours d'exécution. Dans ce cas, procédez comme suit :

  1. Démarrez le service auditd : 

                > 
            sudo
            systemctl start auditd

  2. Activez le service dans les cibles de votre système à l'aide de la commande 

                > 
            sudo
            systemctl enable auditd

Le fichier journal /var/log/audit/audit.log consigne les messages de refus d'accès, les événements de service, etc.

L'Exemple 1: « Exemples de lignes du journal /etc/audit/audit.log » affiche une partie du contenu du journal /var/log/audit/audit.log.

Exemple 1 : Exemples de lignes du journal /etc/audit/audit.log
 
type=DAEMON_START msg=audit(1348173810.874:6248): auditd start, ver=1.7.7 format=raw kernel=3.0.13-0.27-default auid=0 pid=4235 subj=system_u:system_r:auditd_t res=success
type=AVC msg=audit(1348173901.081:292): avc:  denied  { write } for  pid=3426 comm="smartd" name="smartmontools" dev=sda6 ino=581743 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir
type=AVC msg=audit(1348173901.081:293): avc:  denied  { remove_name } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir
type=AVC msg=audit(1348173901.081:294): avc:  denied  { unlink } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:295): avc:  denied  { rename } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582373 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:296): avc:  denied  { add_name } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir
type=AVC msg=audit(1348173901.081:297): avc:  denied  { create } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:298): avc:  denied  { write open } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:299): avc:  denied  { getattr } for  pid=3426 comm="smartd" path="/var/lib/smartmontools/smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.309:300): avc:  denied  { append } for  pid=1316

Un message unique se présente comme suit : 

  type=AVC msg=audit(1348173901.081:299): avc:  denied  { getattr } for  pid=3426 comm="smartd" path="/var/lib/smartmontools/smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file

Chaque ligne du message peut être divisée en sections. Par exemple, les sections de la dernière ligne sont les suivantes :

type=AVC :

Chaque ligne du journal d'audit relative à SELinux commence par l'identification du type, par exemple, type=AVC. Notez qu'un message du type type=SYSCALL qui suit un message d'un autre type et a la même valeur de msg peut fournir des informations supplémentaires concernant l'événement.

msg=audit(1348173901.309:300) :

Il s'agit du tampon horaire, inscrit par rapport à une époque, à savoir, le nombre de secondes écoulées depuis le 1er janvier 1970. Vous pouvez utiliser la commande date ‑d dans la partie précédent le point de la notation horaire de l'époque pour découvrir à quelle date l'événement s'est produit : 

> date -d @1348173901
Thu Sep 20 16:45:01 EDT 2012
avc: denied { append } :

Action spécifique refusée. Dans cet exemple, le système a refusé d'ajouter des données à un fichier. Lorsque vous parcourez le fichier journal d'audit, vous pouvez voir d'autres opérations système, telles que write open, getattr, etc.

for pid=1316 :

ID de processus de la commande ou du processus qui a déclenché l'action

comm="rsyslogd" :

Commande spécifique associée à ce PID

name="smartmontools" :

Nom de l'objet de l'action

dev=sda6 ino=582296 :

Périphérique de bloc et numéro d'inode du fichier concerné

scontext=system_u:system_r:syslogd_t :

Contexte source, qui est le contexte de l'initiateur de l'action

tclass=file :

Identification de classe de l'objet

2 Analyse du journal /var/log/audit/audit.log avec audit2allow

 

Au lieu d'interpréter les événements du journal /var/log/audit/audit.log vous-même, vous pouvez utiliser la commande audit2allow.

La commande facilite l'analyse des messages consignés dans le journal /var/log/audit/audit.log. Une session de dépannage audit2allow est toujours composée de trois commandes différentes. Vous allez commencer par utiliser audit2allow -w -a pour obtenir une présentation plus lisible des informations d'audit. La commande audit2allow -w -a par défaut fonctionne sur le fichier audit.log. Si vous souhaitez analyser un message spécifique du fichier audit.log, copiez-le dans un fichier temporaire et analysez le fichier avec la commande : 

      > 
      sudo
      audit2allow -w -i FILENAME
Exemple 2 : Analyse des messages d'audit
 
> sudoaudit2allow -w -i testfile
type=AVC msg=audit(1348173901.309:300): avc:  denied  { append } for  pid=1316
comm="rsyslogd" name="acpid" dev=sda6 ino=582296
scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:apmd_log_t tclass=file
Ce message a été causé par :

Une règle d'autorisation manquante relative au type d'application (TE - type enforcement).

Pour générer un module chargeable afin d'autoriser cet accès, exécutez : 

            > 
            sudo
            audit2allow

Pour savoir quelle règle spécifique a refusé l'accès, vous pouvez utiliser audit2allow -a pour afficher les règles d'application de tous les événements qui ont été consignés dans le fichier audit.log ou audit2allow -i FILENAME pour afficher les messages que vous avez enregistrés dans un fichier spécifique :

Exemple 3 : Affichage des lignes de refus d'accès
 
> sudoaudit2allow -i testfile
#============= syslogd_t ==============
allow syslogd_t apmd_log_t:file append;

Pour créer un module SELinux nommé mymodule que vous pouvez charger pour autoriser l'accès précédemment refusé, exécutez : 

      > 
      sudo
      audit2allow -a -R -M mymodule

Si vous souhaitez effectuer cette opération pour tous les événements qui ont été consignés dans le fichier audit.log, utilisez les arguments de commande -a -M. Pour le faire uniquement pour certains messages d'un fichier spécifique, utilisez -i -M comme dans l'exemple ci-dessous :

Exemple 4 : Création d'un module de stratégie pour autoriser une opération précédemment refusée
 
> sudoaudit2allow -i testfile -M example
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i example.pp

Comme l'indique la commande audit2allow, vous pouvez maintenant exécuter ce module à l'aide de la commande semodule -i, suivie du nom du module qu'audit2allow a créé pour vous (example.pp dans l'exemple ci-dessus).

3 Analyse des messages AVC à l'aide de l'outil setroubleshoot

 

Pour faciliter l'analyse des messages de refus AVC, vous pouvez utiliser l'outil setroubleshoot.

3.1 Présentation de setroubleshoot

 

3.1.1 Qu'est-ce que setroubleshoot ?

 

setroubleshoot est un outil qui collecte les événements d'audit SELinux du kernel et les analyse. Si ce type d'événement se produit, setroubleshoot en informe l'administrateur.

3.1.2 Composants setroubleshoot

 

Le processus de dépannage de SELinux fait appel aux composants suivants qui sont tous installés par défaut sous SUSE Linux Micro.

  • setroubleshoot-server fournit les outils suivants :

    • setroubleshootd : le daemon principal qui traite les requêtes entrantes et les définitions de plug-ins. Le daemon est activé à la demande et ne nécessite pas d'être exécuté via le service systemd. Il ne peut être géré que par un utilisateur disposant de privilèges et un utilisateur setroubleshoot dédié.

    • une base de données d'alertes dans le fichier /var/lib/setroubleshoot/setroubleshoot_database.xml.

    • sealert : une interface utilisateur de ligne de commande pour analyser le journal /var/log/audit.log.

    • sedispatch : un répartiteur d'audit qui analyse les messages AVC SELinux et les transforme en message DBus, puis les transmet au daemon.

  • setroubleshoot-plugins : les plug-ins sont utilisés pour l'analyse des messages AVC et fournissent des suggestions sur la façon de résoudre les problèmes.

3.1.3 Comment fonctionne setroubleshoot ?

 

setroubleshoot est constitué d'un daemon et de plug-ins d'analyse. Lorsqu'un plug-in détecte un problème, il est signalé au daemon, qui vérifie alors s'il s'agit d'un problème connu. S'il n'est pas encore connu, le nouveau problème est ajouté à la base de données avec une suggestion de solution.

3.1.4 Avantages de l'outil setroubleshoot

 

setroubleshoot fournit les fonctionnalités suivantes pour vous aider à résoudre les problèmes sur vos systèmes SELinux sécurisés :

  • Envoi d'alertes à l'administrateur en cas de refus AVC.

  • Analyse automatique des refus AVC.

  • Suggestion de correctifs possibles, tels que l'ajustement de la configuration du système ou l'installation de mises à jour, etc.

  • Navigation dans les alertes précédentes.

3.2 Configuration de setroubleshoot

 

Même si la configuration de setroubleshoot ne nécessite aucun ajustement, vous pouvez être confronté à des cas d'utilisation spécifiques pour lesquels vous devrez modifier les valeurs par défaut. Les sections suivantes présentent les cas d'utilisation habituels.

Le fichier de configuration de setroubleshoot est /etc/setroubleshoot. Hormis l'activation des notifications par message électronique, il n'est généralement pas nécessaire de modifier la configuration. Toutefois, si vous deviez la modifier, vous pouvez modifier le fichier ou utiliser la commande setroubleshootd pour configurer un élément particulier. La syntaxe de la commande est la suivante : 

        # 
        setroubleshootd -c
SECTION.OPTION=VALUE

Par exemple, pour définir l'option from_address, exécutez la commande comme suit : 

        # 
        setroubleshootd -c
email.from_address="example@mail.com"

3.2.1 Configuration du niveau de consignation pour setroubleshoot

 

Le niveau de consignation par défaut (la valeur de sealert_log et de setroubleshootd_log) est défini sur warning. Toutefois, vous pouvez définir la valeur sur l'une des valeurs suivantes :

critical (critique)

Seules les erreurs graves qui empêchent le système de fonctionner sont consignées.

error (erreur)

Les erreurs graves susceptibles d'avoir un impact sur le système sont signalées.

warning (avertissement)

Indication qu'un événement inattendu s'est produit ou qu'un problème risque de se produire dans un avenir proche. Cependant, le système fonctionne comme prévu.

info

Une confirmation que le système fonctionne correctement est consignée.

debug (débogage)

Des informations détaillées à des fins de débogage sont consignées.

3.2.2 Configuration de setroubleshoot pour l'envoi de notifications par message électronique

 

setroubleshoot peut vous envoyer des notifications par message électronique en cas de refus AVC dans le système.

Pour recevoir ces notifications, procédez comme suit :

  1. Ouvrez le dossier /etc/setroubleshoot/setroubleshoot.conf.

  2. Dans le fichier, définissez les éléments de configuration suivants en fonction de vos besoins :

    smtp_host

    Si le serveur SMTP ne s'exécute pas sur l'hôte local, indiquez l'adresse du serveur.

    smtp_port

    La valeur par défaut est 25. En règle générale, cette valeur ne nécessite aucun ajustement.

    from_address

    Ajoutez l'adresse de l'expéditeur.

    subject

    Configurez un objet générique pour tous les messages.

    recipients_filepath

    Indiquez l'emplacement de la liste des destinataires de la notification.

    use_sendmail

    Définissez cette option sur true si vous utilisez SendMail.

  3. Créez le fichier des destinataires du message dans le chemin défini par l'option recipients_filepath (/var/lib/setroubleshoot/email_alerts-recipients par défaut).

    Chaque adresse électronique doit se trouver sur une ligne distincte. Les commentaires sont signalés par le symbole #.

3.2.3 Configuration de la base de données setroubleshoot

 

Vous pouvez modifier la quantité d'enregistrements dans la base de données setroubleshootd, son emplacement ou le préfixe du nom de fichier.

database_dir

Spécifiez un chemin absolu vers le répertoire dans lequel le fichier XML de la base de données doit se trouver.

filename

Configurez un préfixe personnalisé pour le nom de fichier de la base de données. Le nom du fichier se présente alors comme suit : FILENAME_PREFIX_database.xml.

max_alerts

Définit le nombre maximal d'enregistrements dans la base de données. Spécifiez 0 pour ne pas limiter le nombre d'enregistrements.

max_alert_age

Les alertes antérieures à la limite définie sont supprimées de la base de données. Vous pouvez utiliser les unités : année, mois, jour, heure, minute et seconde même au pluriel et vous pouvez utiliser plusieurs unités, par exemple, 3 weeks 2 days qui équivaut à 23 jours. Si aucune valeur n'est spécifiée, il n'y a pas de limite.

3.2.4 Configuration de setroubleshoot pour collecter des informations à partir de serveurs distants

 

Vous pouvez configurer setroubleshoot pour collecter les données d'audit SELinux à partir de serveurs distants. Pour ce faire, configurez la liste d'adresses.

[listen_for_client] address_list

Du côté du serveur.

[client_connect_to] address_list

Du côté du client.

Les adresses de la liste utilisent le format suivant : 

          [{FAMILY}]ADDRESS[:PORT_NUMBER]

Où {FAMILY} est soit {inet}, soit {unix}%{path}s. Si la famille d'adresses est inet, vous pouvez éventuellement spécifier un numéro de port, sinon le numéro de port est défini sur la valeur par défaut spécifiée par l'option de configuration default_port. La valeur par défaut {unix}%{path}s hostname signifie l'écoute sur le socket du domaine Unix local.

3.3 Exécution de l'analyse du journal /var/log/audit/audit.log

 

Pour permettre à l'outil setroubleshootd'analyser le fichier journal d'audit, exécutez la commande : 

        > 
        sudo
        sealert -a /var/log/audit/audit.log

Dans l'exemple de sortie suivant, deux valeurs de port sont assignées au service SSHD : 

100% done
found 1 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------

SELinux is preventing sshd from name_bind access on the tcp_socket port 2222.

*****  Plugin bind_ports (92.2 confidence) suggests   ************************ 

If you want to allow sshd to bind to network port 2222
Then you need to modify the port type.
Do
# semanage port -a -t PORT_TYPE -p tcp 2222  1
    where PORT_TYPE is one of the following: ssh_port_t, vnc_port_t, xserver_port_t.

*****  Plugin catchall_boolean (7.83 confidence) suggests   ******************

If you want to allow nis to enabled
Then you must tell SELinux about this by enabling the 'nis_enabled' boolean.

Do
setsebool -P nis_enabled 1

*****  Plugin catchall (1.41 confidence) suggests   **************************

If you believe that sshd should be allowed name_bind access on the port 2222 tcp_socket 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 'sshd' --raw | audit2allow -M my-sshd
# semodule -X 300 -i my-sshd.pp

Additional Information:
...

First Seen                    2024-02-07 14:26:27 UTC
Last Seen                     2024-02-08 03:30:12 UTC
Local ID                      b5cbdd75-3f8d-425d-af75-f6cbf1540ffd 

Raw Audit Messages
type=AVC msg=audit(1707363012.797:25): avc:  denied  { name_bind } for  pid=841 comm="sshd" src=2222 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=0


Hash: sshd,sshd_t,unreserved_port_t,tcp_socket,name_bind

1

Le plug-in bind_ports fournit la solution la mieux adaptée à ce problème.