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.