Archive:Fr FR/SELinux/PolitiqueEnforce

Old page
This page has been marked as "old", and likely contains content that is irrelevant or incorrect. If you can, please update this page. This page will be deleted if action is not taken.

Comment SELinux applique les politiques

Premièrement, parlons du processus de démarrage

Quand le noyau SELinux démarre il est codé en dur en se lançant en tant que kernel_t. Puisqu'à ce moment c’est le seul contexte, toutes les applications qui sont exécutées resteront étiquetées kernel_t. Quand le noyau exécute /sbin/init il est à l’origine exécuté en tant que kernel_t, ensuite il lit le fichier de politiques et le charge dans le noyau. À ce moment init se réexécute lui même. Lorsque /sbin/init est installé, il est étiqueté init_exec_t, ensuite une règle dans le noyau précise que lorsque kernel_t exécute une application étiquetée init_exec_t, elle doit être modifiée en init_t. Dès lors, le processus init s'exécute en que init_t.

Le processus init exécute alors /etc/rc.d/rc.sysinit, qui a été étiqueté initrc_exec_t. Le noyau possède une règle qui indique que lorsque init_t exécute initrc_exec_t, il doit le modifier vers initrc_t. Cela continue jusqu'à ce que l’exécutable httpd soit démarré en tant que httpd_t.

Le noyau va maintenant examiner tout accès (en lecture) du domaine de processus (httpd_t) sur la classe (fichier) d’objet du système, par exemple : /var/www/index.html (httpd_sys_content_t). Si une règle dans la politique l'autorise, l’accès sera permis. S'il est refusé, un message AVC (Access Vector Cache) sera inscrit dans le fichier journal. Par ailleurs, ne me critiquez pas pour AVC, je ne suis pas celui qui en a choisi le nom.

À propos de unconfined_t et de la procédure d’ouverture de session

Certaines applications, telles que login, sont autorisées par la politique à définir le contexte du prochain programme exécuté. Actuellement, la plupart des programmes d’ouverture de session utilisent pam_selinux pour avoir ce comportement.

Quand je me connecte alors au système, pam utilise libselinux pour trouver quel est le contexte initial à paramétrer pour l'utilisateur. Sur un sytème à polique ciblée, cela sera unconfined_t. Vous pouvez modifier ce comportement en modifiant les fichiers dans /etc/selinux/POLICYTYPE/contexts/default_contexts et /etc/selinux/POLICYTYPE/contexts/users/ afin que sur un système à politique stricte ou MLS, vous puissiez paramétrer l'ouverture de session d'un terminal local par défaut sur un certain contexte, et sur une connexion distante utiliser un contexte différent ; mais cela est une fonctionnalité avancée.

Ainsi, dès que l'utilisateur est connecté, son shell sera lancé avec unconfined_t ou bien user_t, et chaque accès que l'utilisateur fera passera par le noyau afin d'être sûr que l'accès est autorisé. Evidemment, tout ceci est mis en mémoire tampon afin d'améliorer les performances du système.

NOTE :

Une chose étrange que vous aurez pu remarquer est que suivant la méthode de démarrage d'une application, elle pourra s'exécuter au final dans un contexte différent. Par exemple, si vous exécutez httpd via le script de démarrage de service, il sera lancé en tant que httpd_t, mais si vous l'exécutez directement, il sera lancé en tant que unconfined_t. Pourquoi ? Il y a une règle dans le noyau précisant que unconfined_t exécutant initrc_exec_t sera transposé vers initrc_t, et que initrc_t lancant httpd_exec_t sera transposé vers httpd_t. Il existe une autre règle qui précise que unconfined_t est autorisé à lancer httpd_exec_t sans transposition.

Cela a été une décision consciente prise par les auteurs de la politique afin d'essayer de réduire la confusion. Les domaines les plus confinés ne sont pas autorisés à discuter avec le terminal. Ils ne sont également pas autorisés à lire/écrire dans les répertoires des utilisateurs. La raison pour cela est que nous avons essayer de protéger l'espace utilisateur de l'espace système, et si un domaine cible a été piraté et qu'il lui est possible de lire/écrire sur une console ou un terminal, il pourrait afficher un écran d'ouverture de session et ainsi nous permettre de fournir un nom d'utilisateur et un mot de passe. De même, si un domaine ciblé était capable de lire/écrire dans nos répertoires utilisateur, il pourrait lire nos numéros de carte de crédit, modifier nos scripts d'authenfication, ou plus généralement faire des ravages...

Le problème avec cela est que de temps en temps, les administrateurs exécutent le domaine ciblé avec l'option --help ou veulent tester un script CGI et ne peuvent voir aucun(e) résultat/sortie. Ou voudraient essayer de rediriger la sortie vers leur répertoire utilisateur.

./MonScriptCGI  >> ~toto.out

Si ces domaines venaient à se croiser, ces accès seraient interdits et l'utilisateur pourrait mettre un certain temps à comprendre ce qu'il se passe.

Donc, si vous désirez exécuter un domaine ciblé dans un contexte verrouillé, vous aurez besoin d'utiliser les scripts d'init.