DOCS/UNIX/SElinux

Accueil	SysAdmin	Hobbies

SElinux - petit guide de survie sous Redhat/Centos

SELinux ? quesaquo ?

Security-Enhanced Linux (SELinux) est un mécanisme de sécurité à contrôle d'accès obligatoire (MAC) implémenté dans le noyau GNU/Linux. SELinux a été introduit pour la première fois dans Redhat/CentOS 4 et a été considérablement amélioré dans les versions ultérieures. Ces améliorations signifient que le contenu varie quant à la façon d'aborder SELinux au fil du temps pour résoudre les problèmes.

Quelques-uns des problèmes de sécurité sous Linux

Pour bien comprendre pourquoi SELinux est si important et ce qu'il peut apporter, le plus simple est de passer en revue quelques exemples. Sans SElinux activé sur un système GNU/Linux, seules les méthodes traditionnelles de contrôle d'accès discrétionnaire (DAC) telles que les autorisations sur les fichiers/répertoires ou les listes de contrôles d'accès (ACL) sont utilisées pour contrôler l'accès des utilisateurs aux ressources fichiers. Les utilisateurs et les programmes sont habilités à accorder des autorisations de fichiers non sécurisées à d'autres personnes ou, à l'inverse, à accéder à des parties du système qui ne devraient pas être nécessaires à son fonctionnement normal. Par exemple :

• Les administrateurs n'ont aucun moyen (simple) de contrôler les utilisateurs : Un utilisateur peut définir des permissions de lecture par tout autre utilisateur sur des fichiers sensibles tels que des clés ssh et sur le répertoire contenant ces clés, habituellement : ~/.ssh/
• Les processus peuvent changer les propriétés de sécurité. Un fichier contenant les mails d'un utilisateur ne devrait être lisisble que par son propriétaire, mais un logiciel de messagerie a la possibilité de changer ses propriétés et les rendre lisibles par tout le monde.
• Les processus héritent des droits des utilisateurs qui les exécutent : Firefox par exemple, s'il est compromis par un trojan, serait en mesure de lire la clé privée de l'utilisateur alors qu'il n'a aucune raison de le faire.

Dans le modèle DAC traditionnel, il existe essentiellement deux niveaux de privilèges, celui de l'utilisateur et celui de l'administrateur root, et il n'y a pas de moyen simple d'appliquer un modèle de moindre privilège. De nombreux processus lancés par root perdent ensuite leurs droits d'être exécutés en tant qu'utilisateur restreint et certains processus peuvent être exécutés dans un 'chroot', mais toutes ces méthodes de sécurité sont discrétionnaires et pas toujours réaliseables.

La solution

SELinux suit de beaucoup plus près le modèle des moindre priviléges. Par défaut, dans un cadre d'application stricte, tout est refusé, puis une série de politiques d'exceptions sont rédigées qui donnent à chaque élément du système (un service, un programme ou un utilisateur) uniquement l'accès nécessaire pour fonctionner. Si un service, un programme ou un utilisateur tente par la suite d'accéder ou de modifier un fichier ou une ressource non nécessaire à son fonctionnement, l'accès lui est refusé et l'action est tracée.

Etant donné que SELinux est directement intégré au noyau, les applications n'ont pas besoin d'être spécialement écrites ou modifiées pour fonctionner sous SELinux, bien qu'évidement, si elles sont écrites pour surveiller les codes d'erreurs retournés par SELinux, elles ne pourront que d'autant mieux fonctionner par la suite. Si SELinux bloque une action, cela est signalé à l'application sous-jacente comme une erreur normale (ou, du moins, conventionnelle) de type "accès refusé" à l'application. Cependant, de nombreuses applications ne testent pas tous les codes de retour lors des appels au système et peuvent ne pas renvoyer de message expliquant le problème ou peuvent renvoyer un message trompeur. D'où la réticence de nombreux administrateurs à déployer SELinux sur leurs système.

Les modes de fonctionnement SELinux

SELinux dispose de trois modes de fonctionnement de base, dont le mode Enforcing qui est défini comme mode par défaut à l'installation d'un système. Il existe cependant un qualificatif supplémentaire de targeted ou mls qui contrôle la manière dont les règles SELinux sont appliquées, le niveau targeted étant le moins strict.

• Enforcing : Le mode par défaut qui activera et appliquera la politique de sécurité de SELinux sur le système, en refusant l'accès et en enregistrant les actions

• Permissive : En mode permissif, SELinux est activé mais n'appliquera pas la politique de sécurité, se contentant d'avertir et de consigner les actions. Le mode permissif est utile pour analyser de diagnostiquer les problèmes liés à SELinux

• disabled : SELinux est désactivé

Le mode SELinux peut être consulté et modifié en utilisant l'outil SELinux Management GUI disponible dans le menu Administration ou à partir de la ligne de commande en exécutant "system-config-selinux" (l'outil SELinux Management GUI fait partie du paquet policycoreutils-gui et n'est pas installé par défaut).

Les utilisateurs qui préfèrent la ligne de commande peuvent utiliser la commande sestatus pour afficher l'état actuel de SELinux :

sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      31

La commande setenforce peut être utilisée pour switcher temporairement entre les modes Enforcing et Permissive à chaud. Mais il est important de noter que ce changement n'est pas persistant à la suite d'un reboot system

Pour rendre persistant le mode de fonctionnement de SELinux, il faut editer le fichier de configuration /etc/selinux/config en remplaçant la valeur du paramaètre SELINUX= par 'Enforcing', 'Permissive' ou 'Disabled'. Exemple :

 SELINUX=Permissive

sans utiliser d'éditeur, la commande perl suivante peut s'avérer utile :

perl -pi -e 's/SELINUX=.*$/SELINUX=Permissive/g' /etc/selinux/config

la commande équivalente avec sed

sed -i 's/^SELINUX=.*$/SELINUX=permissive/' /etc/selinux/config

NOTE Lors d'un changement de mode de SELinux, il est très recommandé de rebooter le système et d'effectuer un 'relabel' du filesystem. Cela est même indispensable si on switch des modes Disabled ou Permissive vers Enforcing

SELinux Policy

Comme indiqué, SELinux suit le modèle du moindre privilège ; par défaut, tout est refusé et ensuite une politique est rédigée qui donne à chaque élément du système uniquement l'accès nécessaire pour fonctionner. Cette description décrit le mieux la politique stricte. Cependant, il est difficile d'écrire une politique qui convienne à la large gamme de circonstances dans lesquelles un produit tel que Enterprise Linux est susceptible d'être utilisé. Le résultat final est que SELinux est susceptible de causer des problèmes aux administrateurs système et aux utilisateurs finaux et que, plutôt que de résoudre ces problèmes, les administrateurs système peuvent simplement désactiver SELinux, ce qui met en échec les protections intégrées.

De par sa conception, SELinux permet d'écrire différentes politiques qui sont interchangeables. La politique par défaut dans Redhat/CentOS est la politique Targeted qui "cible" et confine les processus système sélectionnés.

Tous les autres processus du système et tous les programmes restants de l'espace utilisateur, ainsi que toutes les applications internes, c'est-à-dire tout le reste du système, fonctionnent dans un domaine non confiné par défaut et ne sont donc pas couverts par le modèle de protection SELinux.

Un objectif pourrait être que chaque processus installé et, par défaut, fonctionnant au démarrage, soit exécuté dans un domaine confiné. La politique ciblée est conçue pour protéger autant de processus clés que possible sans nuire à l'expérience de l'utilisateur final et la plupart des utilisateurs devraient ignorer totalement que SELinux est en cours d'exécution.

SELinux Access Control

La politique Targeted utilisée sous Redhat/Centos dispose de 4 formes de contrôles d'accès :

• Type Enforcement (TE) : principal mécanisme de contrôle d'accès utilisé dans la politique Tergetetd
• Role-Based Access Control (RBAC) : Basé sur les utilisateurs SELinux (pas nécessairement les mêmes que l'utilisateur Linux), mais non utilisé dans la configuration par défaut de la politique Targeted
• Multi-Level Security (MLS): : Peu utilisé et souvent caché dans la politique Targetetd par défaut.
• Multi-Category Security(MCS): : Une extension de la sécurité à plusieurs niveaux, utilisée dans la politique ciblée pour mettre en œuvre le cloisonnement des machines virtuelles et des conteneurs

Tous les processus et fichiers ont un contexte de sécurité SELinux. Voyons cela en action en examinant le contexte de sécurité SELinux de la page d'accueil d'Apache : /var/www/html/index.html

 ls -lZ /var/www/html/index.html
-rw-------. 1 apache apache sysadm_u:object_r:httpd_sys_content_t:s0 0 11 déc.  17:25 /var/www/html/index.html

NOTE l'option -Z utilisée dans la commande ls fonctionnera avec la majorité des commandes afin de montreer le contexte de sécurité SELinux de la ressource (ex : 'ls -Z', 'ps axZ', id -Z etc ...

En plus des autorisations et des propriétés standards des fichiers, nous pouvons voir les champs de contexte de sécurité SELinux : system_u:object_r:httpd_sys_content_t

Ceci est basé sur user:role:type:mls. Dans l'exemple ci-dessus, les champs user:role:type sont affichés et mls est caché. Dans le cadre de la politique Targeted par défaut, type est le champ important utilisé pour mettre en œuvre l'application du type de context, dans ce cas httpd_sys_content_t.

Considérons maintenant le contexte de sécurité SELinux du processus du serveur web Apache : httpd

ps -axZ | grep httpd
system_u:system_r:httpd_t:s0    38163 ?        Ss     0:00 /usr/sbin/httpd -DFOREGROUND

Ici, nous voyons le champ type (user:role:type) qu'Apache s'exécute sous le domaine de type httpd_t.

Enfin, examinons le contexte de sécurité SELinux d'un fichier dans le home directory d'un utilisateur (ex: franck) :

ls -Z /home/franck/mon_fichier.txt
unconfined_u:object_r:user_home_t:s0 /home/franck/mon_fichier.txt

où nous voyons que le champ 'type' est user_home_t, le type de contexte de sécurité par défaut pour les fichiers contenus dans un home directory utilisateur.

L'accès n'est autorisé qu'entre types similaires, de sorte qu'Apache fonctionnant sous httpd_t peut lire /var/www/html/index.html de type httpd_sys_content_t. Comme Apache tourne dans le domaine httpd_t et ne possède pas le userid:username, il ne peut pas accéder à /home/franck/monfichier.txt même si ce fichier est lisible par tout le monde car le contexte de sécurité SELinux de /home/franck/monfichier.txt n'est pas de type httpd_t. Si Apache devait être exploité, en supposant pour les besoins de cet exemple que le droit du compte root nécessaire pour effectuer un réétiquetage SELinux dans un autre contexte de sécurité n'était pas obtenu, il ne pourrait pas démarrer de processus qui ne se trouveraient pas dans le domaine httpd_t (ce qui empêche l'escalade des privilèges) ni d'accéder à un fichier qui ne se trouverait pas dans un domaine lié à httpd_t.

De la même manière, les processus httpd sont prévus pour utiliser le port 80/tcp. Si pour une raison applicative ce service devait utiliser un autre port et qu'aucune configuration SElinux n'est appliquée pour valider ce changement, le service ne démarrera pas. (cf procédure ci-après pour appiquer un tel changement)

Role-Based Access Control (RBAC)

Bien que la configuration par défaut de la politique Targeted soit d'utiliser des logins non restreints (unconfined_u), l'administrateur peut assez facilement passer au modèle de contrôle d'accès basé sur les rôles. Ce modèle passe également en mode strict pour les domaines des utilisateurs, afin de permettre de cibler chaque programme individuellement. Pour ce faire, utilisez la commande semanage login pour ajouter un mappage de connexion pour un utilisateur (ex : myuser) :

semanage login -a -s "staff_u" -r "s0-s0:c0.c1023" myuser

La commande semanage login associe un nom d'utilisateur Linux à un utilisateur SELinux nommé "staff_u", avec une plage MLS/MCS de "s0-s0:c0.c1023". Après cela, la connexion se traduira par le renvoi de l'id -Z staff_u:staff_r:staff_t:s0-s0:c0.c1023 par opposition à unconfined_u:unconfined_r:unconfined_t:s0. Bien que staff_r ne soit pas un rôle destiné à l'administration, c'est un rôle qui permet à l'utilisateur de passer à d'autres rôles. Lorsqu'un administrateur souhaite effectuer des tâches d'administration du système, il doit passer au rôle sysadm_r en utilisant le drapeau -r dans sudo :

[myuser@localhost ~]$ sudo -r sysadm_r -i
[root@localhost ~]$

Cela peut être automatisé en ajoutant un fichier de configuration sous /etc/sudoers.d/, pour associer l'utilisateur à un rôle d'administrateur par défaut.

%wheel  ALL=(ALL)       TYPE=sysadm_t   ROLE=sysadm_r   ALL

Il est toujours possible de se connecter en tant qu'utilisateur non confiné ou de passer au rôle non confiné via le newrole (-r), les avantages des domaines d'utilisateurs confinés sont alors perdus. Il est également possible de supprimer cette possibilité en créant un nouvel utilisateur SELinux associé uniquement à un ensemble de rôles sélectionné :

semanage user -a -R "staff_r sysadm_r system_r" -r "s0-s0:c0.c1023" my_staff_u

Ensuite, en remplaçant staff_u par my_staff_u dans la commande semanage login. Si vous essayez maintenant de passer au rôle unconfined_r, vous obtiendrez un message AVC et SELINUX_ERR. Si l'administrateur souhaite supprimer complètement la possibilité de se connecter en tant qu'utilisateur non confiné, il doit refaire la connexion __default__ à un utilisateur SELinux plus approprié, en utilisant à nouveau semanage login :

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

Si un utilisateur souhaite se connecter en tant que rôle autre que celui par défaut, c'est au programme de connexion de lui fournir cette fonctionnalité. SSH permet de se connecter avec un autre rôle SELinux en le spécifiant comme faisant partie de l'identifiant de connexion (par exemple, en tant qu'utilisateur du personnel se connectant sous le nom unconfined_r).

ssh myuser/unconfined_r@monserveur.net

Au-delà du modèle strict, le contrôle d'accès basé sur les rôles fournit également un mécanisme permettant de limiter la portée de ce qu'un utilisateur peut faire lorsqu'il utilise sudo pour passer à l'utilisateur root. Il est souvent souhaitable d'appliquer le moindre privilège aux utilisateurs ayant des rôles spécifiques comme les administrateurs de bases de données ou les auditeurs et la politique ciblée comprend plusieurs rôles d'utilisateurs à des fins similaires, avec une documentation dans leurs pages de manuel respectives comme mentionné dans le chapitre #Policy Documentation.

seinfo -r

Roles: 14
   auditadm_r
   dbadm_r
   guest_r
   logadm_r
   nx_server_r
   object_r
   secadm_r
   staff_r
   sysadm_r
   system_r
   unconfined_r
   user_r
   webadm_r
   xguest_r

Pour associer un utilisateur à l'un de ces rôles d'administrateur, la même commande semanage user est utilisée comme précédemment pour créer un nouvel utilisateur SELinux associé aux rôles souhaités, puis semanage login pour associer le login Linux à l'utilisateur SELinux. Si l'utilisateur doit également pouvoir lancer les démons du système qu'il administre à partir de son domaine d'utilisateur (c'est-à-dire pour lancer mysql en tant que dbadm_r pour le débogage à partir d'un shell), le rôle system_r doit être inclus dans sa liste de rôles associés.

semanage user -a -R "staff_r system_r auditadm_r" -r "s0-s0:c0.c1023" auditor_u
semanage login -a -s "auditor_u" -r "s0-s0:c0.c1023" myuser

Multi-Category Security (MCS)

La sécurité multi-catégories permet d'associer un ensemble ou une gamme de compartiments aux contextes SELinux. Le modèle de politique 'Targeted' met en œuvre la compartimentation des types associés à mcs_constrained_type. Pour comprendre comment cela fonctionne, il est nécessaire de savoir comment inspecter la partie MLS des contextes de sécurité. Il s'agit de la partie qui suit la section user:role:type, et comprend une plage, qui indique un niveau de sécurité faible et élevé:

system_u:system_r:httpd_t:s0           -        s0:c0.c5
                          ▼                     ▼
                  Low security level,    High security level, also
                  associated with no     associated with compartments
                  compartments.          c0, c1, c2, c3, c4 and c5.

Une chose que l'on peut remarquer est l'absence de compartiments au niveau sécurité faible, ainsi que le fait que les deux niveaux de sécurité sont les mêmes. Le premier point est un détail de la mise en œuvre du modèle MCS dans la politique ciblée. Lorsqu'un vecteur d'accès est calculé pour un processus qui est associé à mcs_constrained_type, seuls les compartiments MCS du niveau élevé sont comparés. Le deuxième point est dû au fait que le MLS n'est pas utilisé.

La partie compartiment du contexte de sécurité ci-dessus est une gamme de catégories, mais peut aussi être un ensemble de catégories séparées par des virgules. Une gamme de catégories fait que le contexte est associé à un ensemble de catégories inclusives dans cette gamme. Pour comprendre comment l'accès est calculé pour deux processus avec un ensemble de catégories, il faut examiner les règles de dominance pour les niveaux de sécurité SELinux (l'accès n'est autorisé que si le niveau de sécurité élevé du type source domine le niveau de sécurité élevé du type cible). Ces règles sont les suivantes (elles ne tiennent compte que des catégories, et non des niveaux de sécurité MLS)

• La source domine la cible si les catégories du contexte source sont les mêmes que celles du contexte cible ou un sur-ensemble de celles-ci.
• La source est dominée par la cible si les catégories du contexte source sont un sous-ensemble des catégories du contexte cible.
• La source et la cible sont égales et se dominent l'une l'autre si l'ensemble des catégories est le même dans chaque contexte.

En gardant cela à l'esprit, nous savons qu'un contexte ayant un ensemble de catégories c0.c5 aura accès à un contexte ayant un ensemble de catégories c0,c3, mais pas à un ensemble de catégories c0,c6 ou c0.c1023.

Un exemple d'utilisation de la sécurité multi-catégories pourrait être l'utilisation de NGINX avec plusieurs vhosts qui se connectent à des serveurs backend qui fonctionnent également comme des domaines httpd (par exemple, PHP-FPM). Normalement, ces instances de serveurs dorsaux sont capables de modifier et de gérer les domaines des autres, simplement en raison des règles d'application des types. Si elles sont associées à des catégories, elles ne peuvent le faire que si un serveur backend domine l'autre. Comme NGINX est lui-même un domaine HTTPD, il devrait dominer tous les serveurs backend, donc si nous avons des catégories c0 à c5 disponibles pour les domaines HTTPD, nous voudrions exécuter NGINX sous la forme system_u:system_r:httpd_t:s0-s0:c0.c5, afin qu'il puisse se connecter aux serveurs en amont. Chaque serveur en amont fonctionnerait avec une seule catégorie dans c0-c5, et un contexte tel que system_u:system_r:httpd_t:s0-s0:c1.

Il y a quelques conditions préalables pour y parvenir. Premièrement, httpd_t doit être associé à l'attribut mcs_constrained_type qui n'est actuellement associé qu'aux types suivants sur Redhat/CentOS :

seinfo -xamcs_constrained_type

Type Attributes: 1
   attribute mcs_constrained_type;
        container_logreader_t
        container_t
        container_userns_t
        netlabel_peer_t
        openshift_app_t
        openshift_t
        sandbox_min_t
        sandbox_net_t
        sandbox_web_t
        sandbox_x_t
        svirt_kvm_net_t
        svirt_qemu_net_t
        svirt_t
        svirt_tcg_t

Pour ajouter à cette liste de types, il est nécessaire de créer un module de politique locale qui associe le type souhaité à l'attribut. Cela se fait à l'aide de la déclaration type-attribut, et peut être fait de la même manière :

policy_module(httpd_mcs, 1.0)
gen_require(`
    type httpd_t;
    attribute mcs_constrained_type;
')

typeattribute httpd_t mcs_constrained_type;

Une fois que le type est associé à mcs_constrained_type, chaque serveur backend doit voir son contenu relayé pour inclure les catégories respectives dans ses spécifications de contexte de fichier. Cela peut être réalisé en ajoutant les types de fichiers dans /etc/selinux/targeted/contexts/customizable_types, mais cela peut potentiellement être interrompu lors d'une mise à jour de la politique. Une alternative est d'ajouter de nouvelles spécifications de contextes de fichiers qui incluent des catégories en utilisant la commande semanage fcontext :

semanage fcontext -a -t httpd_sys_content_t -r "s0-s0:c1" "/srv/backend1(/.*)?"
semanage fcontext -a -t httpd_sys_content_t -r "s0-s0:c2" "/srv/backend2(/.*)?"

L'étape suivante consiste à s'assurer que les serveurs backend sont démarrés avec un contexte de sécurité correct. Sur Redhat/CentOS avec systemd, cela peut être réalisé avec la directive SELinuxContext= dans le fichier unitaire :

SELinuxContext=system_u:system_r:httpd_t:s0-s0:c1

Maintenant, chaque serveur backend doit être isolé de l'autre, tout en permettant à l'accès NGINX de gérer et d'envoyer des messages aux deux.

Diagnostiquer SELinux

Tôt ou tard, vous pouvez vous retrouver dans des situations où SELinux refuse l'accès à quelque chose et où vous devez résoudre le problème. Il existe un certain nombre de raisons fondamentales pour lesquelles SELinux peut refuser l'accès à un fichier, un processus ou une ressource :

• Un dossier mal étiqueté.
• Un processus fonctionnant dans le mauvais contexte de sécurité SELinux.
• Un bogue dans la politique.
• Une application nécessite l'accès à un fichier qui n'était pas prévu lors de la rédaction de la politique et génère une erreur.
• Une tentative d'intrusion.

Nous pouvons nous occuper des trois premiers cas, alors que donner l'alerte et l'avertissement dans le quatrième cas est exactement le comportement prévu.

Pour résoudre un problème, les fichiers journaux sont la clé et SELinux ne déroge pas à cette règle. Par défaut, les messages de journal de SELinux sont écrits dans /var/log/audit/audit.log via le système d'audit de Linux auditd, qui est lancé par défaut. Si le daemon auditd n'est pas lancé, les messages sont écrits dans /var/log/messages. Les messages SELinux log sont étiquetés avec le mot-clé AVC afin qu'ils puissent être facilement filtrés des autres messages, comme avec grep.

Des outils de dépannage SELinux peuvent être utilisés pour aider à analyser les fichiers journaux en les convertissant dans un format plus lisible par l'utilisateur. L'outil se compose d'une interface graphique permettant d'afficher les messages dans un format lisible par l'utilisateur et les solutions possibles, d'une icône de notification sur le bureau alertant des nouveaux problèmes et d'un processus daemon, setroubleshootd, qui vérifie les nouvelles alertes AVC SELinux et alimente l'icône de notification. Les notifications par courrier électronique peuvent également être configurées, comme pour ceux qui ne disposent pas d'un serveur X. L'outil de dépannage SELinux est fourni par le paquet setroubleshoot. L'outil peut être lancé depuis le menu système du gestionnaire d'interface graphique X Window ou depuis la ligne de commande :

sealert -b 

Pour les réfeactaires au serveur X11 et adaptes de la ligne de commande, ils peuvent générer des rapports lisibles par l'homme à partir de la ligne de commande :

sealert -a /var/log/audit/audit.log > /path/to/mylogfile.txt 

SELinux & Auditd

Comme décrit ci-dessus, SELinux interagit avec auditd pour générer des messages qui aident à la fois à l'audit et au dépannage d'un système. Les types de messages les plus courants qui apparaissent dans le journal d'audit de SELinux sont des CVS. Ils décrivent des opérations qui ont été refusées (ou autorisées) par le serveur de sécurité de SELinux. Bien que les messages AVC soient les plus courants, ils ne sont pas les seuls types de messages générés par SELinux et envoyés au sous-système d'audit.

Principaux messages générés par SELinux
auditd record type	Description
AVC	Messages qui sont générés par le noyau lorsque l'accès à une opération est accordé ou refusé. Les messages d'audit peuvent être générés lorsque l'accès est accordé en utilisant les règles de politique auditallow, et les messages peuvent également être empêchés d'être enregistrés lorsque l'accès est refusé en utilisant les règles dontaudit.
USER_AVC	Semblables aux messages AVC, mais sont générés par des programmes en espace utilisateur qui utilisent le serveur de sécurité SELinux. Ces programmes sont connus sous le nom de gestionnaires d'objets en espace utilisateur, et comprennent D-Bus et systemd.
SELINUX_ERR	Une erreur émise par le serveur de sécurité SELinux dans les cas où une opération échoue et où un AVC ne décrit pas suffisamment le problème. Cela se produit généralement lorsque systemd essaie de passer à un service qui a NoNewPrivileges=True dans son fichier d'unité, mais qui n'a pas de limites de type dans la politique SELinux entre systemd et son propre type. Ce problème spécifique peut également survenir si un processus souhaite que setcon(3) modifie le contexte d'un de ses threads. Il peut également se produire lorsqu'un programme tente de définir un contexte non valide, par exemple, PAM utilise setcon(3) pour passer au domaine des utilisateurs connectés et des connexions SELinux mal configurées peuvent entraîner le renvoi d'un contexte incorrect depuis l'espace utilisateur SELinux.
USER_SELINUX_ERR	Comme pour SELINUX_ERR, des messages de ce type sont enregistrés lorsqu'un gestionnaire d'objets de l'espace utilisateur rencontre une erreur liée à SELinux.
MAC_POLICY_LOAD, USER_MAC_POLICY_LOAD	Un message qui est enregistré lorsqu'une politique SELinux est chargée. La variante USER est également émise par les gestionnaires d'objets de l'espace utilisateur pour les informer qu'ils ont traité le chargement de la politique.
MAC_CONFIG_CHANGE	Un message qui est enregistré lorsqu'un administrateur modifie la valeur d'un booléen SELinux à l'aide de setsebool.
MAC_STATUS	Lorsque le statut de SELinux passe de contraignant à permissif ou inversement.
USER_ROLE_CHANGE	Un message qui est enregistré lorsqu'un utilisateur change de rôle via la commande newrole(1), au moment de la connexion, ou en utilisant sudo. Applicable uniquement au contrôle d'accès basé sur les rôles.
USER_LABEL_EXPORT	Enregistré chaque fois qu'un utilisateur exporte un objet étiqueté en utilisant CUPS.