introduction
Dans cette dernière partie de notre tutoriel sur SELinux, nous parlerons des utilisateurs de SELinux et de la manière d’affiner leur accès. Nous étudierons également les journaux d’erreur SELinux et nous expliquerons comment interpréter les messages d’erreur.
_ * Remarque * + Les commandes, les packages et les fichiers présentés dans ce didacticiel ont été testés sur CentOS 7. Les concepts restent les mêmes pour les autres distributions. _
Dans ce tutoriel, nous exécuterons les commandes en tant qu’utilisateur root, sauf indication contraire. Si vous n’avez pas accès au compte root et utilisez un autre compte avec les privilèges sudo, vous devez faire précéder les commandes du mot-clé + sudo +.
Utilisateurs SELinux
Les utilisateurs SELinux sont des entités différentes des comptes utilisateur Linux normaux, y compris le compte root. Un utilisateur de SELinux n’est pas créé avec une commande spéciale, il n’a pas non plus son propre accès de connexion au serveur. Au lieu de cela, les utilisateurs SELinux sont définis dans la stratégie chargée en mémoire au démarrage, et il n’ya que quelques-uns de ces utilisateurs. Les noms d’utilisateur se terminent par + _u +, tout comme les types ou les noms de domaine se terminent par + _t + et les rôles se terminent par + _r +. Différents utilisateurs de SELinux ont des droits différents sur le système et c’est ce qui les rend utiles.
L’utilisateur SELinux indiqué dans la première partie du contexte de sécurité d’un fichier est l’utilisateur propriétaire de ce fichier. C’est comme si vous voyiez le propriétaire d’un fichier à partir d’une sortie normale de la commande + ls -l +. Une étiquette d’utilisateur dans un contexte de processus indique les privilèges de l’utilisateur SELinux sur lesquels le processus est exécuté.
Lorsque SELinux est appliqué, chaque compte d’utilisateur Linux normal est mappé sur un compte d’utilisateur SELinux. Plusieurs comptes d’utilisateur peuvent être mappés sur le même utilisateur SELinux. Ce mappage permet à un compte régulier d’hériter de l’autorisation de son homologue SELinux.
Pour afficher ce mappage, nous pouvons exécuter la commande + semanage login -l +:
semanage login -lDans CentOS 7, voici ce que nous pouvons voir:
Login Name SELinux User MLS/MCS Range Service
__default__ unconfined_u s0-s0:c0.c1023 *
root unconfined_u s0-s0:c0.c1023 *
system_u system_u s0-s0:c0.c1023 *La première colonne de ce tableau, «Nom de connexion», représente les comptes d’utilisateur Linux locaux. Vous vous demandez peut-être si nous n’avons pas créé quelques comptes dans la deuxième partie de ce didacticiel. Oui, et ils sont représentés par l’entrée indiquée par par défaut . Tout compte utilisateur Linux normal est d’abord mappé sur la connexion par défaut . Ceci est ensuite mappé à l’utilisateur SELinux appelé unconfined_u. Dans notre cas, il s’agit de la deuxième colonne de la première ligne. La troisième colonne indique la classe de sécurité multiniveau / sécurité multizone (MLS / MCS) pour l’utilisateur. Pour l’instant, ignorons cette partie et la colonne suivante (Service).
Ensuite, nous avons l’utilisateur * root . Notez qu’il n’est pas mappé sur le nom de connexion « default *», mais qu’il possède sa propre entrée. Une fois encore, root est également mappé sur l’utilisateur SELinux unconfined_u.
system_u est une classe d’utilisateurs différente, destinée à l’exécution de processus ou de démons.
Pour voir quels utilisateurs de SELinux sont disponibles dans le système, nous pouvons exécuter la commande + semanage user +:
semanage user -lLa sortie dans notre système CentOS 7 devrait ressembler à ceci:
Labeling MLS/ MLS/
SELinux User Prefix MCS Level MCS Range SELinux Roles
guest_u user s0 s0 guest_r
root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
sysadm_u user s0 s0-s0:c0.c1023 sysadm_r
system_u user s0 s0-s0:c0.c1023 system_r unconfined_r
unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r
user_u user s0 s0 user_r
xguest_u user s0 s0 xguest_rQue signifie cette plus grande table? Tout d’abord, il montre les différents utilisateurs de SELinux définis par la stratégie. Nous avions déjà vu des utilisateurs comme unconfined_u et system_u, mais nous voyons maintenant d’autres types d’utilisateurs tels que guest_u, staff_u, sysadm_u, user_u, etc. Les noms sont un peu indicatifs des droits qui leur sont associés. Par exemple, nous pouvons peut-être supposer que l’utilisateur sysadm_u aurait plus de droits d’accès que guest_u.
Pour vérifier notre invité, regardons la cinquième colonne, SELinux Roles. Si vous vous souvenez de la première partie de ce didacticiel, les rôles SELinux sont comme des passerelles entre un utilisateur et un processus. Nous les avons également comparés à des filtres: un utilisateur peut _ entrer_ un rôle, à condition que le rôle le lui accorde. Si un rôle est autorisé à accéder à un domaine de processus, les utilisateurs associés à ce rôle pourront entrer dans ce domaine de processus.
Nous pouvons maintenant voir dans cette table que l’utilisateur + unconfined_u + est mappé aux rôles + system_r + et + unconfined_r +. Bien que cela ne soit pas évident ici, la stratégie SELinux permet en fait à ces rôles d’exécuter des processus dans le domaine + unconfined_t +. De même, l’utilisateur + sysadm_u + est autorisé pour le rôle sysadmr, mais guestu est mappé sur le rôle guest_r. Chacun de ces rôles aura différents domaines autorisés.
Maintenant, si nous reculons un peu, nous avons également vu dans le premier extrait de code que la connexion par défaut était mappée sur l’utilisateur non confinéu, tout comme l’utilisateur root mappait sur l’utilisateur non confiné_u. Étant donné que l’identifiant par défaut _