Contexte de Sécurité
system_u:object_r:httpd_exec_t:s0
Tout dans SELinux tourne autour du Label de Sécurité, ou du Contexte de Sécurité. Tout Sujet (processus) et Objet (habituellement les fichiers de l’ordinateur) possède un contexte de sécurité qui lui est associé. Ce contexte à différent nom suivant à quoi il est attaché. Il est appelé file_context quand il est associé à un fichier. Et il est quelquefois appelé Domaine lorsque associé à un processus.
Le contexte du fichier est stocké avec l’Inode dans un attribut étendu sur les systèmes (de fichier) supportant les attributs étendus. Cela fonctionne de la même manière que les DAC (explication ??!) et les ACLs (Access Control List/Liste de Contrôle d’Accès). En cela, la sécurité du fichier est basée sur les informations stockées dans l’Inode et non dans le chemin d’accès au fichier.
Sur les systèmes de fichiers qui ne supportent pas les attributs étendus, le noyau fournis les contextes de fichier. Par exemple, il existe une règle sur les systèmes SELinux qui précise que tous les fichiers situés sur un volume NFS monté seront labélisés system_u:object_r:nfs_t
Maintenant, regardons ce qui forme un contexte de sécurité.
Un contexte de sécurité est formé de 3 ou 4 parties séparés par ":" Je vais décrire ces composants en commençant du dernier vers le premier.
4ème partie: Partie MLS
La quatrième partie est le champ MLS qui n'est pas supporté dans RHEL 4 ou Fedora Core 4. On peut l'apercevoir en à partir de Fedora Core 5, toutefois, il existait dans les versions précédentes de SELinux mais n'avais jamais été activé.
Cette composante est utilisée par toutes les politiques chargées avec Fedora Core 5. Avec les politiques Strictes et Ciblées, nous nous y référons en tant que champs MCS. Malheureusement, ce champ peut contenir le signe ":". La syntaxe de ce champ peut ressembler à cela : s0-s15:c1,c2. Mais je parlerais plus tard de la syntaxe. La plupart des fichiers sont par défaut estampillés s0, parfois, ont fait allusion à SystemLow. Heureusement, SELinux fournit une bibliothèque de traduction qui remplace les codes du champ par une forme plus lisible. Alors, quelque chose comme S0:c1,c2 peut être affiché à l'utilisateur comme PatientRecord,CompanyConfidential. Sur une machine ou la politique est Stricte ou Ciblée, s0 est traduit "", alors la plupart des fichiers n'afficheront pas tous le quatrième champ.
3ème partie: Types
La troisième composante du contexte de sécurité est le champ Type, par exemple, /usr/sbin/httpd est labélisé avec le type “httpd_exec_t. Mon opinion est que ceci est le champ le plus important dans le contexte de sécurité SELinux. C’est le cœur du Type Enforcement de SELinux. La plupart des politiques SELinux tournent autour de quel Type de Sujet ont quels accès à quels Types d’Objet. Par convention, cette composante se termine toujours par “_t”
2nde partie: Rôles
La seconde partie du Contexte de Sécurité est le champ Rôle. Ce champ n’est pertinent uniquement sur les Processus ou les Domaines. Le rôle sur un fichier est toujours object_r, est n’a vraiment aucune signification autre que de remplir le champ. Sur un Processus, vous verrez généralement un rôle comme system_r ou sysadm_r. Les rôles sont utilisés pour grouper les Types de Sécurité. Vous pouvez donc spécifier dans une politique quels rôles sont capables d’exécuter quels Types. Ceci est la base des RBAC (Roles Based Access Control/ Contrôle d’Accès Basé sur les Roles) dans SELinux. RBAC ne sont pas réellement utilisés dans les politiques Ciblés, mais deviennent plus important dans les politiques Strictes et MLS. Les politiques MLS contiennent aussi sysadm_r, staff_r, and secadm_r. Par convention, les rôles se terminent toujours par "_r"
1ère partie: Utilisateurs
La première composante du Contexte de Sécurité est le champ "Utilisateur SELinux". Ce composant peut être considéré comme une manière de regrouper les rôles. Les Utilisateurs SELinux peuvent avoir des multiples rôles, et ensuite, dans ces rôles, ils peuvent avoir de multiples types. Les trois utilisateurs que vous verrez généralement sur le système sont "user_u", "system_u" et root. L’utilisateur user_u est l’utilisateur SELinux par défaut pour un utilisateur connecté sur le système. "system_u" est l’utilisateur par défaut pour les processus exécutés durant la phase de démarrage. Ils n’ont jamais été démarrés par un utilisateur. "root" est l’utilisateur SELinux que vous obtenez quand vous vous connectez sur la console en tant que "root". Dans les politiques Ciblées la composante utilisateur n’est pas vraiment importante. Cela l’est plus sur les machines à politiques MLS ou strictes. Sur un fichier le champ utilisateur indique l’utilisateur SELinux qui à créé le fichier. Sur les fichiers original du système, les fichiers sont labélisés system_u. Si vous les re-labélisez ils obtiendront de nouveau le label system_u. Par convention, tous les utilisateurs SELinux se terminent par "_u" sauf pour root. De base, si vous souhaitez faire correspondre un utilisateur Linux à un utilisateur SELinux, vous devrez créer un utilisateur SELinux avec le même nom que l’utilisateur Linux. C’est pour cela que l’utilisateur root ne se termine pas par "_u". Dans les nouvelles versions de SELinux, nous avons ajouté un fichier de mappage "seusers" qui vous permet de faire la correspondance entre les utilisateurs Linux et SELinux sans avoir à créer bon nombre d’utilisateur SELinux.