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.

NOTE Il existe plusieurs autres événements d'audit liés à SELinux qui sont utilisés dans IPSec/NetLabel et qui ne sont pas couverts ici pour le moment. Ces événements sont les suivants : MAC_UNLBL_ALLOW, MAC_UNLBL_STCADD, MAC_UNLBL_STCDEL, MAC_MAP_ADD, MAC_MAP_DEL, MAC_IPSEC_EVENT, MAC_CIPSOV4_ADD, MAC_CIPSOV4_DEL.

Bien que sealert soit très utile pour interpréter les enregistrements AVC, les outils d'audit peuvent donner à l'administrateur une vue plus précise du journal d'audit. ausearch peut être utilisé pour rechercher des événements spécifiques dans le journal d'audit, et dispose d'une variété d'options disponibles pour travailler avec les enregistrements d'audit. Ainsi, au lieu d'interpréter les messages à l'aide de sealert, il est possible d'examiner les causes potentielles des problèmes de SELinux à l'aide d'ausearch. Les types que nous voulons généralement examiner lors du dépannage d'un problème sont AVC, USER_AVC, SELINUX_ERR et USER_SELINUX_ERR. ausearch fournit une option -m qui prend une liste de types d'enregistrements d'audit séparés par des virgules pour les filtrer, ainsi qu'un drapeau -i qui fait que les valeurs numériques soient interprétées en chaînes de caractères selon le système. Cela inclut la conversion des UID/GID en noms d'utilisateur et de groupe, ainsi que le mappage d'une paire d'appel système et d'architecture en nom d'appel système :

ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -i

Recherche de documents et création d'un point de contrôle, pour s'assurer que les documents d'audit qui ont déjà été vus n'apparaissent pas à nouveau lors de la prochaine recherche :

ausearch --checkpoint="./audit-checkpoint" -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -i

La recherche d'enregistrements basée sur le nom de commande des processus, c'est le nom de l'exécutable de la tâche dans le noyau :

ausearch -c "httpd" -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -i

Trouver les événements où un administrateur (ou un programme) a changé l'état d'application de SELinux :

ausearch -m MAC_STATUS -i

Comme il est possible d'empêcher l'enregistrement des enregistrements d'audit en utilisant dontaudit, il est possible que tous les messages AVC ou USER_AVC ne soient pas vus. Pour éviter que les règles dontaudit ne masquent ces messages, l'administrateur peut exécuter le semodule -DB pour reconstruire sa politique SELinux sans les règles dontaudit. Après avoir reproduit le problème, il devrait y avoir plus de messages disponibles qu'auparavant, ainsi que certains enregistrements qui ne sont pas pertinents pour le problème (noatsecure, rlimitinh, et siginh sont des autorisations qui sont toujours vérifiées lorsqu'un programme est exécuté et peuvent généralement être ignorées). Lorsque vous avez terminé l'examen des enregistrements empêchés par les règles de dontaudit, exécutez le semodule -B pour reconstruire la politique avec les rôles de dontaudit inclus à nouveau.

L'inverse est la capacité d'enregistrer les opérations qui réussissent grâce à auditallow. Ces journaux peuvent être recherchés par filtrage des opérations réussies (bien que cela renvoie également les événements réussis en mode permissif) :

ausearch -m AVC,USER_AVC -i --success yes

Réétiquetage des fichiers

La commande chcon peut être utilisée pour modifier le contexte de sécurité SELinux d'un fichier ou de plusieurs fichiers/répertoires de la même manière que les commandes "chown" ou "chmod" peuvent être utilisées pour modifier la propriété ou les autorisations standard d'un fichier.

Examinons quelques exemples.

En utilisant Apache comme exemple, supposons que vous vouliez modifier le DocumentRoot pour servir des pages web à partir d'un emplacement autre que le répertoire /var/www/html/ par défaut. Supposons que nous créions un répertoire (ou peut-être un point de montage) à /html/ et que nous y créions un fichier index.html :

# mkdir /html
# touch /html/index.html
# ls -Z /html/index.html
-rw-r--r--  root root user_u:object_r:default_t        /html/index.html
# ls -Z | grep html
drwxr-xr-x  root root user_u:object_r:default_t        html

Nous voyons que le répertoire /html/ et le fichier /html/index.html ont tous deux le type de contexte de sécurité : default_t. Si nous démarrons notre navigateur web et essayons de visualiser la page, SELinux refusera correctement l'accès et enregistrera l'erreur parce que le répertoire et le(s) fichier(s) ont le mauvais contexte de sécurité. Nous devons définir le type de contexte de sécurité correct pour Apache de : httpd_sys_content_t.

# chcon -v --type=httpd_sys_content_t /html
context of /html changed to user_u:object_r:httpd_sys_content_t
# chcon -v --type=httpd_sys_content_t /html/index.html
context of /html/index.html changed to user_u:object_r:httpd_sys_content_t
# ls -Z /html/index.html
-rw-r--r--  root root user_u:object_r:httpd_sys_content_t    /html/index.html
# ls -Z | grep html
drwxr-xr-x  root root user_u:object_r:httpd_sys_content_t    html

De même, nous aurions pu régler les deux en une seule fois en utilisant le commutateur récursif -R :

# chcon -Rv --type=httpd_sys_content_t /html 

La modification des contextes de sécurité de cette manière persistera entre les redémarrages du système, mais seulement jusqu'à ce que la partie modifiée du système de fichiers soit réétudiée. Cette opération n'est pas rare et la bonne solution, après test, est d'écrire une règle locale personnalisée (appelée module de politique) et de la fusionner avec les règles locales de base. Il s'agira d'une règle supplémentaire qui s'ajoutera aux plus de 200 règles mentionnées ci-dessus. Pour rendre permanent le changement du contexte de sécurité, même par un réétiquetage complet du système de fichiers, nous pouvons utiliser l'outil de gestion SELinux ou la commande "semanage" de la ligne de commande :

semanage fcontext -a -t httpd_sys_content_t "/html(/.*)?" 

pour ajouter un contexte de fichier de type httpd_sys_content_t pour tout ce qui se trouve sous /html.

Récupérer les contexts de sécurité par défaut

La commande restorecon peut être utilisée pour restaurer les contextes de sécurité SELinux par défaut du ou des fichiers.

Encore une fois, prenons l'exemple d'Apache. Supposons qu'un utilisateur modifie une copie de index.html dans son répertoire personnel et déplace (mv) le fichier vers le DocumentRoot /var/www/html. Alors que la commande copy (cp) adopte généralement le contexte de sécurité du répertoire ou du fichier de destination, move (mv) maintient le contexte de sécurité du source. Nous pourrions utiliser la commande "chcon" pour modifier le contexte de sécurité du ou des fichiers en question, mais comme le ou les fichiers sont maintenant dans le répertoire par défaut d'Apache DocumentRoot (/var/www/html), nous pouvons simplement restaurer les contextes de sécurité par défaut pour ce répertoire ou ce(s) fichier(s). Pour restaurer uniquement le fichier index.html, nous utiliserons :

# restorecon -v /var/www/html/index.html 

ou de restaurer récursivement les contextes de sécurité par défaut pour l'ensemble du répertoire :

# restorecon -Rv /var/www/html 

De plus, si nous voulions simplement examiner les contextes de sécurité du répertoire /var/www/html pour voir si certains fichiers ont besoin que leur contexte de sécurité soit restauré, nous pouvons utiliser restorecon avec le commutateur -n pour empêcher tout réétiquetage :

# restorecon -Rv -n /var/www/html 

Dans certains cas, il se peut également que l'utilisateur ait déplacé des fichiers dont le type est répertorié dans /etc/selinux/targeted/contexts/customizable_types</ode>. Ces types sont traités comme spéciaux par restorecon, en ce sens qu'ils ne seront généralement pas relayés par restorecon à moins que le drapeau -F supplémentaire ne soit passé. En effet, ces types sont soit associés à des catégories (comme mentionné dans Sécurité multi-catégories), soit des types de contenu utilisateur que l'utilisateur est autorisé à personnaliser. Pour réétiqueter un contenu auquel un type personnalisable est associé, exécutez restorecon comme ci-dessus avec le drapeau supplémentaire :

1. restorecon -RvF /var/www/html

Réétiquetage complet du filesystem

Il est parfois nécessaire de ré-étiqueter le système de fichiers complet, bien que cela ne soit nécessaire que lors de l'activation de SELinux après qu'il ait été désactivé ou lors de la modification de la politique SELinux de la politique ciblée par défaut à la politique stricte. Pour ré-étiqueter automatiquement le système de fichiers complet au redémarrage, il suffit de :

# touch /.autorelabel
# reboot 

NOTE Après l'application de la procédure de récupération du mot de passe root par exemple, il est indispensable d'effectuer un réétiquetage complet du filesystem

Autoriser l'accéè à un port

Nous pourrions souhaiter qu'un service tel qu'Apache soit autorisé à lier et à écouter les connexions entrantes sur un port non standard. Par défaut, la politique SELinux n'autorisera l'accès des services qu'aux ports reconnus associés à ces services. Si nous voulons permettre à Apache d'écouter sur le port tcp 81, nous pouvons ajouter une règle pour l'autoriser en utilisant la commande semanage :

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

Une liste complète des ports auxquels les services sont autorisés à accéder par SELinux peut être obtenue acvec la commande :

# semanage port -l  

Collecter les logs d'audit en mode permissif

Lorsqu'un programme se voit refuser une opération à plusieurs reprises par SELinux, il est parfois plus facile de poursuivre le débogage en mode permissif. L'opération habituelle pour cela est setenforce 0, qui met tous les domaines du système en mode permissif plutôt que le seul domaine du processus rencontrant un problème. Pour éviter cela, SELinux supporte le concept des types permissifs, permettant à l'administrateur de mettre un seul domaine en mode permissif plutôt que le système entier.

Pour ce faire, sur la base d'une entrée de journal d'audit, il suffit d'examiner le type dans le contexte du champ scontext :

type=AVC msg=audit(1218128130.653:334): avc:  denied  { connectto } for  pid=9111 comm="smtpd" path="/var/spool/postfix/postgrey/socket"
scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket

Le voici : postfix_smtpd_t. Pour autoriser temporairement l'accès à toute opération souhaitée par ce domaine, nous pouvons utiliser la semanage pour ajouter un nouveau type permissif :

semanage permissive -a postfix_smtpd_t

Nous pouvons maintenant regarder les journaux d'audit pour voir ce que postfix_smtpd_t doit être autorisé à faire pour fonctionner avec succès. Une fois que nous avons terminé, nous pouvons remettre ce type en mode d'exécution :

semanage permissive -d postfix_smtpd_t

Cette approche ne souffre pas de la lourdeur du setenforce 0 et permet à tous les autres services du système de continuer à bénéficier des contrôles d'accès de SELinux.

Créer des politiques de sécurité SELinux customisées avec audit2allow

Il arrive parfois qu'aucune des méthodes ci-dessus ne permette de traiter une situation donnée et nous devons étendre la politique SELinux en créant un module de politique personnalisé pour permettre un certain ensemble de conditions. Prenons par exemple le module complémentaire du service Postgrey pour un serveur de messagerie smtp. Notre serveur smtp doit communiquer avec postgrey sur une socket Unix et c'est quelque chose que la politique SELinux par défaut de notre serveur smtp ne permet pas. Par conséquent, le service est bloqué par SELinux. C'est un problème qui ne peut pas être résolu en modifiant ou en restaurant les contextes de sécurité des types de fichiers et ce n'est pas quelque chose qui a une valeur booléenne que nous pouvons autoriser par basculement. Nous pourrions désactiver la protection SELinux du serveur smtp par le biais d'un booléen, ce qui serait mieux que de désactiver complètement SELinux, mais c'est encore loin d'être idéal.

Si nous passons SELinux en mode permissif et que nous faisons fonctionner notre serveur de messagerie pendant une période déterminée, nous pouvons enregistrer les problèmes de SELinux tout en autorisant l'accès (comme mentionné dans la section "Collecter les journaux d'audit en mode permissif"). En vérifiant nos journaux, nous voyons les messages AVC SELinux suivants :

type=AVC msg=audit(1218128130.653:334): avc:  denied  { connectto } for  pid=9111 comm="smtpd" path="/var/spool/postfix/postgrey/socket"
scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
type=AVC msg=audit(1218128130.653:334): avc:  denied  { write } for  pid=9111 comm="smtpd" name="socket" dev=sda6 ino=39977017
scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:object_r:postfix_spool_t:s0 tclass=sock_file 

Nous pouvons ensuite utiliser audit2allow pour générer un ensemble de règles qui permettraient les actions requises. Nous pouvons générer un fichier local de politique d'application de type postgrey (postgreylocal.te) :

# grep smtpd_t /var/log/audit/audit.log | audit2allow -m postgreylocal > postgreylocal.te
# cat postgreylocal.te
module postgreylocal 1.0;
require {
        type postfix_smtpd_t;
        type postfix_spool_t;
        type initrc_t;
        class sock_file write;
        class unix_stream_socket connectto;
}
#============= postfix_smtpd_t ==============
allow postfix_smtpd_t initrc_t:unix_stream_socket connectto;
allow postfix_smtpd_t postfix_spool_t:sock_file write;

Nous voyons ci-dessus que nous pouvons greffer le fichier audit.log pour les problèmes liés à notre serveur smtp et les transmettre à audit2allow qui génère un ensemble de règles qui, selon lui, autorisent les actions actuellement refusées par la politique de SELinux. En examinant ces règles, nous constatons que notre serveur smtp veut se connecter et écrire sur une socket Unix qui, comme nous le voyons dans nos journaux, est la socket Unix sur laquelle le service postgrey est à l'écoute. Comme cela semble parfaitement raisonnable, nous pouvons utiliser audit2allow pour créer un module de politique personnalisé permettant ces actions :

# grep smtpd_t /var/log/audit/audit.log | audit2allow -M postgreylocal 

Nous chargeons ensuite notre module de politique post-Grey en utilisant la commande semodule dans la politique SELinux actuelle :

# semodule -i postgreylocal.pp 

qui ajoutera notre module de politique post-gris à /etc/selinux/targeted/modules/active/modules/postgreylocal.pp. Nous pouvons vérifier que le module politique est correctement chargé en inscrivant semodule -l sur la liste des modules chargés.

Nous pouvons ensuite continuer à surveiller nos fichiers journaux SELinux pour vérifier que notre module de politique personnalisé fonctionne et, une fois que nous sommes satisfaits, nous pouvons réactiver le mode SELinux Enforcing et bénéficier à nouveau de la protection SELinux de notre serveur smtp désormais pleinement fonctionnel.

Résumé

Cet article est destiné à donner un aperçu du travail avec SELinux pour les utilisateurs novices. SELinux est installé et activé par défaut, et pour la plupart des utilisateurs, il fonctionnera sans problème en offrant un niveau de sécurité accru. SELinux convient à toutes les catégories d'installation, y compris les serveurs, les stations de travail, les ordinateurs de bureau et les ordinateurs portables.

Bien que SELinux puisse sembler assez intimidant et complexe pour les utilisateurs qui ne le connaissent pas, ce n'est pas une raison pour le désactiver à l'installation. Si SELinux présente des problèmes, il est facile de passer en mode permissif, où les problèmes sont uniquement enregistrés et non bloqués. Lorsque des problèmes surviennent, les techniques présentées dans cet article peuvent être utilisées pour les dépanner et les résoudre.