Archive:Fr FR/SELinux/PolitiqueEnforce

= 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. 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  il est à l’origine exécuté en tant que , ensuite il lit le fichier de politiques et le charge dans le noyau. À ce moment  se réexécute lui même. Lorsque  est installé, il est étiqueté , ensuite une règle dans le noyau précise que lorsque   exécute une application étiquetée  , elle doit être modifiée en. Dès lors, le processus  s'exécute en que.

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

Le noyau va maintenant examiner tout accès (en lecture) du domaine de processus sur la classe (fichier) d’objet du système, par exemple :. 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, 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  pour avoir ce comportement.

Quand je me connecte alors au système,  utilise   pour trouver quel est le contexte initial à paramétrer pour l'utilisateur. Sur un sytème à polique ciblée, cela sera. Vous pouvez modifier ce comportement en modifiant les fichiers dans  et   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  ou bien , 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  via le script de démarrage de service, il sera lancé en tant que , mais si vous l'exécutez directement, il sera lancé en tant que. Pourquoi ? Il y a une règle dans le noyau précisant que  exécutant   sera transposé vers , et que   lancant   sera transposé vers. Il existe une autre règle qui précise que  est autorisé à lancer   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'.