\documentclass{report}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{textcomp}
\usepackage{geometry}
\geometry{top=15mm, bottom=15mm, left=1cm, right=1cm}
\usepackage[french]{babel}
\usepackage{pslatex}
\usepackage[colorlinks=true,urlcolor=black]{hyperref}
\usepackage{graphicx}
\usepackage{fancyhdr}
\pagestyle{fancy}
\renewcommand{\footrulewidth}{0.4pt}
\fancyfoot[L]{Uubu.fr}
\fancyfoot[R]{mar. mai 16 15:25:11 CEST 2017}
\lfoot{\Large \textit{Uubu.fr}}
\hypersetup{pdfinfo={
Title={SELinux},
Author={Sylvain Girod},
Creator={Bash script from uubu.fr's format version 1},
Producer={Bash script and PDFLaTeX},
Subject={SElinux est un mécanisme de contrôle d'accès obligatoire (MAC) pour les distributions GNU/Linux. C'est un développement dans la continuité de FLASK},
CreationDate={D:20170516152511},
ModDate={D:20170516152511},
Keywords={rbac;selinux;DAC;MAC}
}}
\begin{document}
 
\begin{center}
{\Huge SELinux }
\end{center}
\vspace{1cm}
 
\begin{flushleft}
 
{\large SElinux est un mécanisme de contrôle d'accès obligatoire (MAC) pour les distributions GNU/Linux. C'est un développement dans la continuité de FLASK}
 
\vspace{10mm}
 
\vspace{1cm}{\huge Répertoires }
 
\
 
\begin{description} \normalsize
\item[\hspace{1mm} /sys/fs/selinux]{Le système de fichier SELinux qui interface avec le service de sécurité du kernel.}
\item[\hspace{1mm} /etc/selinux]{La configuration pour selinux}
\item[\hspace{1mm} /var/lib/selinux/<SELINUXTYPE>/module]{Modules de stratégie SELINUX}
\end{description}
 
\vspace{1cm}{\huge Utilité }
 
\
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{Si SELinux est activé, la stratégie définie quels accès aux ressource et les opérations sur ces ressources (ex: read, write) sont autorisés. C'est un mécanisme MAC}
\item[\hspace{1mm} -]{Le concept de stratégie, l'implémentation et les tests avec une stratégie de sécurité définie ou les pre-requis sont importants.}
\item[\hspace{1mm} -]{SELinux pour confiner une application avec son propre domaine et lui permettre d'avoir les privilèges minimum pour faire son job. Si l'application nécessite un accès aux réseaux ou d'autres application (ou leur données), alors cet accès est donné.}
\item[\hspace{1mm} -]{Si une application 'fait quelque chose" qui n'est pas permis par stratégie, SELinux peut stopper ces actions}
\item[\hspace{1mm} -]{Si une application fait quelque chose qui est permis par stratégie, SELinux peut contenir tout dégât qui peut être fait intentionnellement ou non. Par exemple, si une application est autorisée à supprimer tout ses fichiers de données ou entrées de base de données et qu'un bug, virus ou utilisateur gagne ces privilèges, il peut faire la même chose, cependant, si cette stratégie confine l'application et les données, toutes les autres données ne seront pas touchées.}
\item[\hspace{1mm} -]{Les sessions login utilisateur peuvent être confinés dans leur propre domaine. Cela permet aux clients qu'ils lancent d'avoir seulement les privilèges nécessaires. Cela confine/limite également tout dommage ou fuite de données.}
\item[\hspace{1mm} -]{Certaines applications sont difficiles à confiner parce qu'elles sont généralement conçues pour avoir un accès total à toutes les ressources. SELinux peut généralement gérer ce problème en fournissant des services sandboxing.}
\item[\hspace{1mm} -]{SELinux ne stoppe pas les fuites mémoire, ou débordement de tampon, cependant il peut contenir les dommages qui peuvent être faits.}
\item[\hspace{1mm} -]{SELinux ne stop pas tous les virus/malware dans le système, cependant il devrait limiter les dégats ou fuites qu'ils causent.}
\item[\hspace{1mm} -]{SELinux ne stop pas les vulnérabilités, cependant, il peut limiter leurs effets.}
\item[\hspace{1mm} -]{Il est facile d'ajouter de nouvelles règles à une stratégie SELinux en utilisant des outils tels que audit2allow(1) si un utilisateur a les permissions nécessaires.}
\item[\hspace{1mm} -]{SELinux ne peut pas stopper ce qui est autorisé par stratégie, donc un bon design est important.}
\end{description}
 
\vspace{1cm}{\huge Composants du cœur SELinux }
 
\
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{Un sujet qui doit être présent pour déclencher une action à prendre par un objet.}
\item[\hspace{1mm} -]{Un gestionnaire d'objet qui connaît les actions requises pour la ressource particulière et peut forcer ces actions}
\item[\hspace{1mm} -]{Un serveur de sécurité qui prend les décisions au regard des droits du sujet pour effectuer l'action requise sur l'objet, basé sur les règles de stratégie de sécurité}
\item[\hspace{1mm} -]{Une Stratégie de sécurité qui décris les règles utilisant le language de stratégie SELinux}
\item[\hspace{1mm} -]{Un cache de vecteur d'accès qui améliore les performances système.}
\end{description}
 
{\includegraphics[]{../images/selinux01.png}}
 
{\includegraphics[]{../images/selinux02.png}}
 
\hspace{1mm}  Le schéma ci-dessus montre un diagramme plus complexe du kernel et userspace avec les services support qui sont utilisés pour gérer l'environnement SELinux. En partant du bas:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{Dans l'implémentation actuelle de SELinux le serveur de sécurité est embarqué dans le kernel et les stratégies sont chargées depuis le userspace via une série de fonctions contenues dans la librairie libselinux. Le gestionnaire d'objet (OM) et le cache de vecteur d'accès (AVC) peuvent résider dans:}
\end{description}
 
\begin{description} \normalsize
\item[\hspace{6mm} kernelspace]{Cette gestion d'objet est pour les services kernel tel que les fichiers, répertoires, socket, IPC, etc. et sont fournis par des hooks dans le sous-système SELinuyx via le framework LSM. Le service AVC du kernel est utilisé pour maintenir en cache les réponses du serveur de sécurité.}
\item[\hspace{6mm} userspace]{Cette gestion d'objet est fournie avec l'application ou service qui nécessite un support pour MAC et sont des applications "SELinux-aware". Par exemple, X-Windows, D-bus, PostgreSQL, nscd, et passwd. Généralement, ces OM utilisent les services AVC construits dans la librairie SELinux, cependant il peuvent fournir leur propre AVC si besoin.}
\end{description}
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{La stratégie de sécurité SELinux et ses fichiers de configuration sont contenus dans /etc/selinux. Ce répertoire contient le fichier de configuration principal qui a le nom du la stratégie à charger et le mode d'application de la stratégie au chargement.}
\item[\hspace{1mm} SELinux supporte une stratégie modulaire, ce qui signifie qu'une stratégie n'a pas à être une grande stratégie, mais peut être construite avec des modules. Une stratégie modulaire consiste d'une stratégie de base qui contient les informations obligatoires, et 0 ou plusieurs modules de stratégie où chacune supporte une application particulière ou service. Ces modules sont compilés, liés et maintenus dans un magasin de stratégie.]{-}
\item[\hspace{1mm} Pour être capable de construire la stratégie, une source de stratégie est requise, qui peut être fournie de 3 manières:]{}
\end{description}
 
\begin{description} \normalsize
\item[\hspace{6mm} -]{Un code source écrit en langage de stratégie SELinux.}
\item[\hspace{6mm} -]{En utilisant la statégie référence, qui a des macros haut-niveau pour définir les règles.}
\item[\hspace{6mm} -]{En utilisant CIL (Common Intermediate Language).}
\item[\hspace{6mm} ]{}
\end{description}
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{Pour pouvoir compiler les sources de stratégie puis les charger dans le serveur de sécurité, un certains nombre d'outils sont requis}
\item[\hspace{1mm} -]{Pour permettre à un administrateur de gérer les stratégies, l'environnement SELinux et les systèmes de fichier labélisés, outils et commandes gnu/linux modifiés sont utilisées.}
\item[\hspace{1mm} -]{Pour s'assurer que les évènements de sécurité sont loggés, gnu/linux a un service d'audit qui capture les violations de stratégie.}
\item[\hspace{1mm} -]{SELinux supporte les services réseaux.}
\end{description}
 
\vspace{1cm}{\huge Mandatory Access Control (MAC) }
 
\
 
\hspace{1mm}  MAC est un type de contrôle d'accès dans lequel le système d'exploitation est utilisé pour contraindre un utilisateur ou processus (le sujet) de l'accès ou un opération sur un objet (tel qu'un fichier, mémoire, etc.). Chaque sujet et objet a un jeu d'attributs de sécurité qui peuvent être interrogés par l'os pour vérifier si l'opération demandée peut être effectuée ou non. Pour SELinux:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{Les sujets sont des processus}
\item[\hspace{1mm} -]{Les objets sont des ressources système tels que des fichiers, sockets, etc.}
\item[\hspace{1mm} -]{Les attributs de sécurité sont des contextes de sécurité}
\item[\hspace{1mm} -]{Le serveur de sécurité dans le kernel autorise l'accès ou non en utilisant la stratégie de sécurité qui décris les règles définies.}
\end{description}
 
\hspace{1mm}  Noter que le sujet ne peut pas décider de bypasser les règles de stratégie définie par la stratégie MAC avec SELinux. En contraste avec DAC de Linux, qui gouverne également la capacité des sujets à accéder aux objets, cependant il permet aux utilisateurs de décider de la stratégie. Les étapes dans les décisions DAC et MAC:
\vspace{5mm} \\
 
 
{\includegraphics[]{../images/selinux03.png}}
 
\hspace{1mm}  SELinux supporte 2 formet de MAC:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} Type Enforcement]{Où les traitements lancés dans les domaines et les actions sur les objets sont contrôlés par la stratégie. C'est l'implémentation utilisée pour MAC dans SELinux avec RBAC}
\item[\hspace{1mm} Multi-Level Security]{C'est une implémentation basée sur le modèle BLP, et utilisée par les organisations où différents niveaux d'accès sont requis pour que les informations restreintes soient séparées des informations classifiée pour maintenir la confidentialité.}
\end{description}
 
\hspace{1mm}  Les services MLS/MCS sont utilisés pour maintenir une séparation d'applications, par exemple:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{Les machines virtuelles utilisent les catégories MCS pour permettre à chaque VM de se lancer dans son propre domaine.}
\item[\hspace{1mm} -]{Les périphériques Android utilisent les catégories MCS pour qu'une application qui tourne à la demande d'un utilisateur ne puisse pas lire ou écrire des fichiers créé par la même application à la demande d'un autre utilisateur.}
\end{description}
 
\vspace{1cm}{\huge Utilisateurs SELinux }
 
\
 
\hspace{1mm}  Les utilisateur dans gnu/linux sont généralement associés avec des utilisateurs humain (comme Alice et Bob) ou des fonctions d'opérateur/système (comme admin), bien que celà puisse être implémenté dans SELinux, les noms d'utilisateur SELinux sont généralement des groupes ou des classes d'utilisateur. Par exemple, tous les utilisateurs système standard peuvent être assignés à un nom d'utilisateur user\_u et l'équipe d'administration sous staff\_u.
\vspace{5mm} \\
 
 
\hspace{1mm}  Il y a un utilisateur SELinux spécial définis qui ne doit jamais être associé à un utilisateur gnu/linux vu qu'il est une identité spéciale pour les processus et objets système, cet utilisateur est system\_u.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le nom d'utilisateur SELinux est le premier composant d'un contexte de sécurité et par convention les noms d'utilisateur SELinux se terminent en '\_u', cependant ce n'est pas obligatoire.
\vspace{5mm} \\
 
 
\hspace{1mm}  Il est possible d'ajouter des contraintes et limites dans les utilisateurs SELinux.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge RBAC }
 
\
 
\hspace{1mm}  Pour contrôler l'accès aux domaines, TE SELinux utilise RBAC. Cette fonctionnalité permet aux utilisateurs de SELinux d'être associés à un ou plusieurs rôles, où chaque rôle est ainsi associé à un ou plusieurs types de domaine.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le nom du rôle SELinux est le second composant d'un contexte de sécurité, et par convention les rôle SELinux se terminent par '\_r'.
\vspace{5mm} \\
 
 
\hspace{1mm}  Il est possible d'ajouter des contraintes et limites sur les rôles.
\vspace{5mm} \\
 
 
{\includegraphics[]{../images/selinux04.png}}
 
\vspace{1cm}{\huge Type Enforcement }
 
\
 
\hspace{1mm}  SElinux utilise un style spécifique de technologie TE pour forcer le contrôle d'accès obligatoire. Pour SELinux cela signifie que tous les sujets et objets ont un identifiant de type associé avec eux qui peut être utilisé pour forcer les règles établies par stratégie.
\vspace{5mm} \\
 
 
\hspace{1mm}  L'identifiant de type SELinux est une simple chaîne de longueur variable qui est définie dans la stratégie et associée à un contexte de sécurité. Il est également utilisé dans la majorité des règles et déclaration du langage SELinux utilisés pour construire un stratégie qui va, une fois chargée dans le serveur de sécurité, forcer la stratégie via les gestionnaires d'objet.
\vspace{5mm} \\
 
 
\hspace{1mm}  Parce que l'identifiant de type (ou simplement type) est associé à tous les sujets et objets, il peut parfois être difficile de distinguer le type actuellement associé. Il revient de comprendre comment ils sont alloués dans la stratégie elle-même et comment ils sont utilisé par les services SELinux.
\vspace{5mm} \\
 
 
\hspace{1mm}  Basiquement si l'identifiant de type est utilisé pour référencer un sujet il réfère à un processus Linux ou une collection de processus (un domaine ou un type de domaine). Si l'identifiant de type est utilisé pour référencer un objet alors il spécifie son type d'objet (ex: type de fichier).
\vspace{5mm} \\
 
 
\hspace{1mm}  Bien que SELinux réfère à un sujet comme étant un processus actif qui est associé à un type de domaine, le périmètre d'un domaine TE SELinux peut varier largement. Par exemple dans la stratégie simple construite dans le répertoire basic-selinux-policy des sources, tous les processus dans le système tournent dans le domaine unconfined\_t, et donc tout processus est de type unconfined\_t (qui signifie qu'il peut faire ce qu'il veut dans les limites de la stratégie DAC Linux vu que tous les accès sont autorisés par SELinux).
\vspace{5mm} \\
 
 
\hspace{1mm}  C'est seulement quand des déclarations de stratégie additionnelles sont ajoutées à cette stratégie simple que les zone commencent à être confinées. Par exemple, un passerelle externe est lancée dans son propre domaine isolé (ext\_gateway\_t) qui ne peut pas interférer avec un processus unconfined\_t (excepté pour lancer ou transiter le processus gateway dans son propre domaine). Ce scénario est similaire à la stratégie targeted livrée en standard dans Hed Hat Fedora où la majorité des processus en userspace tournent dans le domaine unconfined\_t.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le type SELinux est le troisième composant d'un contexte de sécurité et par convention les types SELinux se terminent par '\_t'.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Contraintes }
 
\
 
\hspace{1mm} Il est possible d'ajouter des contraintes sur les utilisateurs, rôles, types, et plages MLS, par exemple dans un environnement TE, la manière dont les sujets sont autorisés à accéder à un objet se fait via une règle allow, par exemple:
 
{\ttfamily
allow unconfined\_t ext\_gateway\_t : process transition;\\
}
\vspace{8mm}
 
\hspace{1mm} Cela status qu'un processus tournant dans le domaine unconfined\_t a la permission de transiter un processus au domaine ext\_gateway\_t. Cependant on pourrait souhaiter contraindre cela et statuer que cela se produit seulement si le rôle du domaine source est le même que le rôle du domaine cible:
 
{\ttfamily
constrain process transition ( r1 == r2 );\\
}
\vspace{8mm}
 
\hspace{1mm}  Qui status qu'une transition de processus peut seulement se produire si le rôle source est le même que le rôle cible, cependant un contrainte est une condition qui doit être satisfaite pour une ou plusieurs permission à autoriser ( une contrainte impose des restrictions additionnelles aux règles TE). Noter que la contrainte est basée sur une classe d'objet (un processus dans ce cas), et une ou plusieurs de ses permissions.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Limites }
 
\
 
\hspace{1mm}  Il est possible d'ajouter des limites aux utilisateurs, rôles, et types, cependant actuellement les types sont forcés par le kernel en utilisant la règle typebounds.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Contexte de sécurité }
 
\
 
\hspace{1mm}  SELinux exige un contexte de sécurité à associer avec tout processus ( ou sujet) et objet qui sont utilisé par le serveur de sécurité pour décider si l'accès est autorisé ou non comme définis par la stratégie.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le contexte de sécurité est également connu comme un label de sécurité, ou simplement label qui peut créer la confusion vu qu'il y a de nombreux types de labels dépendants du contexte.
\vspace{5mm} \\
 
 
\hspace{1mm} Dans SELinux, un contexte de sécurité est représenté comme un chaîne de longueur variable qui définis l'utilisateur SELinux, son rôle, un identifiant de type et une plage de sécurité MCS/MLS optionnel:
 
{\ttfamily
user:role:type\texttt{[}:range\texttt{]}\\
}
\vspace{8mm}
 
\begin{description} \normalsize
\item[\hspace{1mm} user]{L'identité de l'utilisateur SELinux. Peut être associé à un ou plusieurs rôles que l'utilisateur SELinux est autorisé à utiliser}
\item[\hspace{1mm} role]{Le rôle SELinux. Cela peut être associé à un ou plusieurs types que l'utilisateur SELinux est autorisé à accéder}
\item[\hspace{1mm} type]{Quand un type est associé avec un processus, il définis quels processus ( ou domaines ) l'utilisateur SELinux ( le sujet ) peut accéder.}
\item[\hspace{1mm} range]{Ce champ peut également être appelé level et est seulement présent si la stratégie supporte MCS ou MLS. L'entrée peut consister de :}
\end{description}
 
\begin{description} \normalsize
\item[\hspace{6mm} -]{Un niveau de sécurité simple qui contient le niveau de sensibilité et 0 ou plusieurs catégories (ex: s0, S1:c0, s7:c10.c15}
\item[\hspace{6mm} -]{Une plage qui consiste de 2 niveaux de sécurité (un faible et un élevé) séparés par un '-' (ex: s0 - s15:c0.c1023)}
\end{description}
 
\hspace{1mm}  Cependant, noter que:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1]{les décisions d'accès au regard du sujet utilisent tous les composant du contexte de sécurité.}
\item[\hspace{1mm} 2]{Les décisions d'accès à un objet utilise les composant comme suit:}
\end{description}
 
\begin{description} \normalsize
\item[\hspace{6mm} a)]{L'utilisateur est soit un jeu d'utilisateur spécial appelé system\_u ou définis à un utilisateur SELinux du processus créant. Il est possible d'ajouter des contraintes sur les utilisateurs dans la stratégie basée sur leur classe d'objet (un exemple de cela est la stratégie de référence UBAC)}
\item[\hspace{6mm} b)]{Le rôle est générallement définis à un rôle SELinux interne spécial object\_r, bien que la stratégie supporte les transitions de rôle dans toute classe d'objet. Il est ainsi possible d'ajouter des contraintes dans les rôles dans la stratégie basée sur leur classe d'objet.}
\end{description}
 
\hspace{1mm} L'exemple ci-dessous montre les contextes de sécurité pour les processus, répertoires et fichier ( noter que la stratégie ne supporte pas MCS ou MLS )
 
{\ttfamily
LABEL\hspace{2mm}\hspace{2mm}\hspace{2mm}\hspace{2mm}PID\hspace{2mm}TTY\hspace{2mm}CMD\\ unconfined\_u:unconfined\_r:unconfined\_t 2539 pts/0 bash\\ unconfined\_u:message\_filter\_r:ext\_gateway\_t 3134 pts/0 secure\_server\\ unconfined\_u:message\_filter\_r:int\_gateway\_t 3138 pts/0 secure\_server\\ unconfined\_u:unconfined\_r:unconfined\_t 3146 pts/0 ps\\
}
\vspace{8mm}
 
\hspace{1mm} Exemple de contexte de sécurité d'objet:
 
{\ttfamily
system\_u:object\_r:in\_queue\_t /usr/message\_queue/in\_queue\\ system\_u:object\_r:out\_queue\_t /usr/message\_queue/out\_queue\\
}
\vspace{8mm}
 
\hspace{1mm} Il y a les contextes de sécurité d'objet de file de message pris depuis la commande ls -Z:
 
{\ttfamily
/usr/message\_queue/in\_queue:\\ unconfined\_u:object\_r:in\_file\_t Message-1\\ unconfined\_u:object\_r:in\_file\_t Message-2\\ /usr/message\_queue/out\_queue:\\ unconfined\_u:object\_r:out\_file\_t Message-10\\ unconfined\_u:object\_r:out\_file\_t Message-11\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Sujets }
 
\
 
\hspace{1mm}  Un sujet est une entité active généralement sous la forme d'une personne, processus, ou périphérique qui cause l'information de transiter dans les objets, ou changent l'état système.
\vspace{5mm} \\
 
 
\hspace{1mm}  Dans SELinux un sujet est un processus actif et a un contexte de sécurité qui lui est associé, cependant un processus peut également être réferré à un objet en fonction du contexte dans lequel il est pris, par exemple:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Un processus en cours de fonctionnement est un sujet parce il créé un flux d'informations ou peut changer l'état système}
\item[\hspace{1mm} 2.]{Le processus peut également être réferré à un objet parce que chaque processus a une classe objet associé appelé process. Cet objet process définis quelles permissions la stratégie est autorisée à donner ou refuser dans le processus actif.}
\end{description}
 
\hspace{1mm}  Dans SELinux les sujets peuvent être:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} trusted]{Généralement ce sont des commandes, applications, etc. qui ont été écrits ou modifiés pour supporter SELinux. Cependant, il peut également couvrir toute application qui est trusté considéré comme faisant partie du système. Bien que - en fonction de votre niveau de paranoïa - la meilleur stratégie est de ne rien truster tant que la conformité avec la stratégie n'a pas été vérifiée. Généralement ces application trustées se lancent soit dans leur propre domaine (ex le service audit peut être sous auditd\_t) ou groupés ensemble (ex semanage et semodule sont groupés sous semanage\_t).}
\item[\hspace{1mm} untrusted]{Tout le reste}
\item[\hspace{1mm} ]{}
\end{description}
 
\vspace{1cm}{\huge Objets }
 
\
 
\hspace{1mm}  Dans SELinux un objet est une ressource telle que des fichiers, sockets, pipes, ou interfaces réseaux qui sont accédés via les processus (les sujets). Ces objets sont classés en accord avec la ressource qu'ils fournissent avec les permissions d'accès significatif pour leur but (ex: lire, reçevoir et écrire), et assigné à un contexte de sécurité.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Classes objet et permissions }
 
\
 
\hspace{1mm}  Chaque objet consiste d'un identifiant de classe qui définis son but (ex: file, socket) avec un jeu de permissions qui décrivent quels services l'objet peut gérer. Quand un objet est instantié, un nom et un contexte de sécurité lui sont alloués.
\vspace{5mm} \\
 
 
{\includegraphics[]{../images/selinux05.png}}
 
\hspace{1mm}  L'objectif de la stratégie est de permettre à l'utilisateur de l'objet (le sujet) d'accéder aux permissions minimum nécessaires pour accomplir la tâche.
\vspace{5mm} \\
 
 
\hspace{1mm}  Ces classes d'objet et leur permissions associées sont construits dans le kernel GNU/Linux et les gestionnaires d'objet en userspace et sont donc généralement mis à jours par ceux qui écrivent les stratégies.
\vspace{5mm} \\
 
 
\hspace{1mm}  Ces classes d'objet consistent de classes objet kernel (pour gérer les fichiers, sockets, etc) plus les classes d'objet en userspace pour les gestionnaires d'objet userspace (pour les services tels que X-Window ou dbus). Le nombre de classes d'objet et leur permissions peut varier en fonction des fonctionnalité configurées dans GNU/Linux.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Autoriser un processus à accéder aux ressources }
 
\
 
\hspace{1mm}  C'est un simple exemple qui tente d'expliquer 2 points:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Comment un processus reçois la permission d'utiliser une ressource}
\item[\hspace{1mm} 2.]{En utilisant la classse objet 'process', montrer qu'un processus peut être décris comme un processus ou un objet.}
\end{description}
 
\hspace{1mm}  Une stratégie contient de nombreuses règles et déclaration, la majorité sont les règle allow qui autorise les permissions d'accès à des processus sur des ressources.
\vspace{5mm} \\
 
 
\hspace{1mm} La règle allow suivante illustre une processus qui peut être également un objet vu qu'il permet aux processus dans le domaine unconfined\_t, la permission transition de l'application gateway externe dans la domaine ext\_gateway\_t une fois qu'il a été exécuté:
 
{\ttfamily
allow Rule | source\_domain | target\_type : classs | permission\\ allow unconfined\_ ext\_gateway\_t : process transition;\\
}
\vspace{8mm}
 
\begin{description} \normalsize
\item[\hspace{1mm} allow]{Défini une règle allow}
\item[\hspace{1mm} unconfined\_t]{Le domaine source (ou sujet) dans ce cas le shell qui souhaite exécuter l'application gateway}
\item[\hspace{1mm} ext\_gateway\_t]{L'objet cible, l'instance objet du processus gateway}
\item[\hspace{1mm} process]{La classe objet de la cible}
\item[\hspace{1mm} transition]{La permission est donné au domaine source dans l'objet cible. Dans ce cas, le domaine a la permission transition dans l'objet process ext\_gateway\_t}
\end{description}
 
\vspace{1cm}{\huge labeliser les objets }
 
\
 
\hspace{1mm}  Dans un système GNU/Linux, labéliser les objets est géré par le système et généralement caché aux utilisateurs. Vu que les processus et les objets sont créés et détruits, soit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Ils héritent leur labels du processus ou objet parent}
\item[\hspace{1mm} 2.]{Le type de stratégie, rôle et plage de transition permettent un label différent.}
\item[\hspace{1mm} 3.]{Les applications gérant SELinux peuvent forcer un nouveau label (avec approbation des stratégies) en utilisant les fonctions de l'API libselinux}
\item[\hspace{1mm} 4.]{Un gestionnaire d'objet (OM) peut forcer un label par défaut qui peut soit être construit dans l'OM ou obtenu via un fichier de configuration}
\item[\hspace{1mm} 5.]{Utiliser un identifiant de sécurité initial (ou initial SID). Il sont définis dans toute stratégie de base et monolitiques et sont utilisé pour définis soit un contexte initial durant le processus de boot, ou si un objet nécessite un défaut.}
\end{description}
 
\hspace{1mm}  Le langage de stratégie SELinux supporte les déclaration de labélisation pour les services fichier et réseau.
\vspace{5mm} \\
 
 
\hspace{1mm}  La labélisation des systèmes de fichier qui implémentent les attributs étendus sont supportés par SELinux en utilisant:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{La déclaration fs\_use\_xattr dans la stratégie pour identifier quels système de fichier utilisent les attributs étendus. Cette déclaration est utilisée pour informer le serveur de sécurité de la manière de labéliser le système de fichier.}
\item[\hspace{1mm} 2.]{Un fichier 'file contexts' qui définis quels contexts initiaux devraient être pour chaque fichier et répertoires dans le système de fichier.}
\item[\hspace{1mm} 3.]{Une méthode pou initialiser le système de fichier avec des attributs étendus. fixfiles et setfiles sont utilisés pour celà. Il y a également des commandes comme chcon, restorecon, et restorecond.}
\end{description}
 
\hspace{1mm}  Les attributs étendus contenant le contexte SELinux d'un fichier peut être vu par les commande ls -Z et getfattr.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Copier et déplacer des fichiers }
 
\
 
\hspace{1mm}  En assumant que les permissions ont été données correctement par la stratégie, les effets dans le contexte de sécurité d'un fichier quand il est copié ou déplacé sont:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} Copie d'un fichier]{- prend le label du nouveau répertoire}
\item[\hspace{1mm} Déplacement d'un fichier]{- Conserve le label du fichier}
\end{description}
 
\hspace{1mm}  Cependant, si le service restorecond fonctionne et que le fichier restorecond.conf est configuré correctement, d'autres contextes de sécurité peuvent être associés au fichier dans ces cas. Noter qu'il y a également la commande install qui supporte -Z pour spécifier le contexte.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Labéliser des sujets }
 
\
 
\hspace{1mm}  Dans un système GNU/Linux, les processus héritent du contexte de sécurité du processus parent. Si le nouveau processus lancé a la permission de changer son contexte, une transition de type est autorisé. Le langage de stratégie supporte plusieurs déclaration pour assigner les composant aux contextes de sécurité tel que des déclarations \textbf{user}, \textbf{role}, et \textbf{type}, et gère leur scope \textbf{role\_allow}, et \textbf{constrain}, et gère leur transition \textbf{type\_transition}, \textbf{role\_transition} et \textbf{range\_transition}.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Réutilisation d'objet }
 
\
 
\hspace{1mm}  GNU/Linux créé des instances des objets et gère les informations qu'ils contiennent (read, write, modify, etc.) sous le contrôle des processus, et à certaines étapes ces objets peuvent être supprimés ou relâchés permettant à la ressource d'être de nouveau disponible.
\vspace{5mm} \\
 
 
\hspace{1mm}  GNU/Linux gère la réutilisation d'objet en s'assurant que quand une ressource est ré-allouée elle est correcte. Cela signifie que quand un processus relâche une instance d'objet (par exemple relâcher de la mémoire allouée dans le pool, supprimer une entrée répertoire ou fichier), Il peut y avoir des informations restantes. Si c'est un problème, le processus lui-même devrait effacer ou détruire les informations avant de relâcher l'objet.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Calculer les contextes de sécurité }
 
\
 
\hspace{1mm}  SELinux utilise des déclarations de langage de stratégie et les fonctions de libselinux pour calculer un contexte de sécurité via le serveur de sécurité.
\vspace{5mm} \\
 
 
\hspace{1mm}  Quand les contextes de sécurité sont calculés, le kernel, outils en userspace et versions de stratégie peuvent influencer la sortie. À cause des patches qui ont été appliqués pendant des années qui donnent une grande flexibilité dans le calcul des contextes. Le contexte de sécurité est calculé pour un objet en utilisant les composants suivants: un contexte source, un contexte cible et une classe objet.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Calcule de contexte de sécurité pour les objets Kernel }
 
\
 
\hspace{1mm}  La tâche initiale commence avec le contexte de sécurité kernel, mais le processus 'init' va typiquement faire une transition dans son propre contexte unique (ex: init\_t), quand le binaire init est exécuté après que la stratégie ait été chargée. Certains programmes init se ré-exécutent eux-même après avoir chargé la stratégie, alors que dans d'autres cas le chargement de la stratégie initiale est effectuée par le script initrd/initramfs avant de monter le vrai root et exécuter le vrai init.
\vspace{5mm} \\
 
 
\hspace{1mm}  Les processus héritent de leur contexte de sécurité comme suit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Lors d'un fork, un processus hérite du contexte de sécurité de son créateur/parent}
\item[\hspace{1mm} 2.]{Lors de l'exécution, un processus peut transiter vers un autre contexte de sécurité basé sur les déclarations de stratégie: type\_transition, range\_transition, role\_transition, default\_user, default\_role, default\_range et default\_type ou si un processus compatible SELinux appel setexeccon(3) si autorisé par la stratégie avant d'invoquer exec.}
\item[\hspace{1mm} 3.]{À tout moment, un processus compatible SELinux peut invoquer setcon(3) pour basculer son contexte de sécurité (si permis) bien que cette pratique soit généralement découragée.}
\end{description}
 
\hspace{1mm}  Le comportement par défaut pour le label de fichier (actuellement les inodes qui consistent des classes suivantes:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Le composant utilisateur est hérité du processus créateur}
\item[\hspace{1mm} 2.]{Le composant rôle est généralement par défaut object\_r}
\item[\hspace{1mm} 3.]{Le composant type est par défaut au type du répertoire parent si aucune règle type\_transition n'est spécifiée dans la stratégie}
\item[\hspace{1mm} 4.]{Le composant range/level est par défaut au niveau bas/courant du processus créateur si aucune règle range\_transition n'est spécifié dans la stratégie}
\end{description}
 
\hspace{1mm}  Les applications compatibles SELinux peuvent changer ce comportement par défaut en appelant setfscreatecon(3) avant de créer le fichier, si permis par la stratégie.
\vspace{5mm} \\
 
 
\hspace{1mm}  Pour les fichiers existants le label est déterminé depuis la valeur xattr associée avec le fichier. S'il n'y a pas de valeur xattr définie dans le fichier, le fichier est traité comme s'il était labélisé avec le contexte de sécurité par défaut pour le système de fichier. Par défaut, c'est le SID "file" initial, qui est mappé à un contexte par la stratégie. Ce défaut peut être écrasé via l'option de montage defcontext=.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Descripteurs de fichier }
 
\
 
\hspace{1mm}  Hérite du label de son créateur/parent.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Systèmes de fichier }
 
\
 
\hspace{1mm}  Les systèmes de fichier sont labélisé en utilisant la déclaration de langage de stratégie kernel fs\_use quand ils sont monté, et sont basés sur le nom du type de système de fichier (ex: ext4) et leur comportement (ex: xattr). Par exemple si la stratégie spécifie:
\vspace{5mm} \\
\hspace{1mm}  \textbf{fs\_use\_task pipefs system\_u:object\_r:fs\_t:s0}
\vspace{5mm} \\
\hspace{1mm}  lorsque le système de fichier pipefs est monté, le hook de sécurité LSM SELinux selinux\_set\_mnt appelle security\_fs\_use qui va:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} a)]{Rechercher le nom du système de fichier dans la stratégie (pipefs)}
\item[\hspace{1mm} b)]{Si présent, obtenir sont comportement (fs\_use\_task)}
\item[\hspace{1mm} c)]{Puis obtenir le contexte de sécurité alloué (system\_u:object\_r:fs\_t:s0)}
\end{description}
 
\hspace{1mm}  si le comportement est définis par fs\_use\_task, alors le système de fichier sera labélié comme suit:
\vspace{5mm} \\
 
 
\hspace{1mm}  Notes:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Les systèmes de fichier qui supportent les attributs étendus xattr peuvent être identifiés via la commande mount, le mot clé seclabel est présent}
\item[\hspace{1mm} 2.]{Il y a des points de montages pour allouer différents types de contexte: context=, fscontext=, defcontext= et rootcontext=}
\end{description}
 
\vspace{1cm}{\huge nfsv4 }
 
\
 
\hspace{1mm}  Si le label NFS est implémenté via le support xattr, la création des inodes sont créés comme décris ci-dessus
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge sockets INET }
 
\
 
\hspace{1mm}  Si un socket est créé par l'appel socket(3), il est labélisé comme suit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Le composant utilisateur hérite du processus créateur}
\item[\hspace{1mm} 2.]{Le composant rôle hérite du processus créateur}
\item[\hspace{1mm} 3.]{Le composant type hérite du processus créateur si aucune règle type\_transition n'est spécifié dans la stratégie}
\item[\hspace{1mm} 4.]{Le composant range/level hérite du processus créateur si aucune règle range\_transition n'est spécifié dans la stratégie}
\end{description}
 
\vspace{1cm}{\huge IPC }
 
\
 
\hspace{1mm}  Hérite le label de son processus d'envoie. Cependant si l'envois d'un message est non labélisé, calcule un nouveau label basé sur le processus courant et met le message en queue comme suit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Le composant utilisateur hérite du processus émetteur}
\item[\hspace{1mm} 2.]{Le composant rôle hérite du processus émetteur}
\item[\hspace{1mm} 3.]{Le composant type hérite du processus émetteur si aucune règle type\_transition n'est spécifiée dans la stratégie}
\item[\hspace{1mm} 4.]{Le composant range/level hérite du processus émetteur si aucune règle range\_transition n'est spécifiée dans la stratégie}
\end{description}
 
\vspace{1cm}{\huge Sémaphores }
 
\
 
\hspace{1mm}  Hérite du label de son créateur/parent
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Mémoire partagée }
 
\
 
\hspace{1mm}  Hérite du label de son créateur/parent
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Clés }
 
\
 
\hspace{1mm}  Hérite du label de son créateur/parent
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Transition d'objet et de domaine }
 
\
 
\hspace{1mm}  La déclaration type\_transition est utilisée pour:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{La transition d'un processus d'un domaine à un autre (une transition de domaine)}
\item[\hspace{1mm} 2.]{La transition d'un objet d'un type à un autre (une transition d'objet)}
\end{description}
 
\vspace{1cm}{\huge Transition de domaine }
 
\
 
\hspace{1mm}  Une transition de domaine se produit lorsqu'un processus dans un domaine démarre un nouveau processus dans un autre domaine sous un contexte de sécurité différent. Il y a 2 manière de définir une transition de domaine:
\vspace{5mm} \\
 
 
\hspace{1mm} 1. En utilisant une déclaration type\_transition, où l'appel système exec va exécuter automatiquement la transition de domaine pour les programmes non compatible SELinux. C'est la méthode la plus commune:
 
{\ttfamily
type\_transition unconfined\_t secure\_services\_exec\_t : process ext\_gateway\_t;\\
}
\vspace{8mm}
 
\hspace{1mm} 2. Les applications compatible SELinux peuvent spécifier le domaine du nouveau processus en utilisant libselinux. Pour cela, l'application doit avoir la permission setexec:
 
{\ttfamily
allow crond\_t self : process setexec;\\
}
\vspace{8mm}
 
\hspace{1mm}  Cependant, avant toute transition de domaine la stratégi doit spécifier que:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Le domaine source a la permission de transiter dans le domaine cible}
\item[\hspace{1mm} 2.]{Le binaire de l'application doit être exécutable dans le domaine source}
\item[\hspace{1mm} 3.]{Le binaire de l'application doit avoir un point d'entrée dans le domaine cible}
\end{description}
 
\hspace{1mm} La déclaration type\_transition suivante est un exemple pour expliquer le processus de transition:
 
{\ttfamily
type\_transition | source\_domain | target\_type | class | target\_domain;\\ type\_transition unconfined\_t secure\_services\_exec\_t : process ext\_gateway\_t;\\
}
\vspace{8mm}
 
\hspace{1mm}  Cette déclaration type\_transition status que lorsqu'un processus dans le domain unconfined\_t exécute un fichier labélisé secure\_services\_exec\_t, le processus doivent être changé en ext\_gateway\_t si permis par la stratégie.
\vspace{5mm} \\
 
 
\hspace{1mm}  Cependant, comme statué plus haut, pour être capable de transiter dans le domaine ext\_gateway\_t, les permissions minimum suivantes doivent être donnés dans la stratégie en utilisant les règles alow, où:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Le domaine nécessite la permission de transiter dans le domaine ext\_gateway\_t:}
\item[\hspace{1mm} allow unconfined\_t : process transition;]{}
\item[\hspace{1mm} 2.]{Le fichier exécutable doit être exécutable dans le domaine unconfined\_t, et donc nécessite également que le fichier soit lisible: allow unconfined\_t secure\_services\_exec\_t : file \verb|{| execute read getattr \verb|}|;}
\item[\hspace{1mm} 3.]{Le fichier exécutable doit avoir un point d'entrée dans le domaine ext\_gateway\_t:}
\item[\hspace{1mm} allow ext\_gateway\_t secure\_services\_exec\_t : file entrypoint;]{}
\end{description}
 
\hspace{1mm}  Comme affiché ci-dessous où unconfined\_t fork un processus enfant, le nouveau programme transite dans ext\_gateway\_t. Noter qu'à cause de la déclaration type\_transition utilisée, la transition est automatiquement géré par le kernel.
\vspace{5mm} \\
 
 
{\includegraphics[]{../images/selinux06.png}}
 
\vspace{1cm}{\huge Règles de type forcé }
 
\
 
\hspace{1mm} En construisant les modules ext\_gateway.conf et int\_gateway.conf l'intention était d'avoir ces transitions et leur domaines respectifs via les déclarations type\_transition. La déclaration ext\_gateway\_t serait:
 
{\ttfamily
type\_transition unconfined\_t secure\_services\_exec\_t : process ext\_gateway\_t;\\
}
\vspace{8mm}
 
\hspace{1mm} et la déclaration int\_gateway\_t serait:
 
{\ttfamily
type\_transition unconfined\_t secure\_services\_exec\_t : process int\_gateway\_t;\\
}
\vspace{8mm}
 
\hspace{1mm} Cependant, en liant ces 2 modules dans la stratégie, l'erreur suivante se produit:
 
{\ttfamily
semodule -v -s modular-test -i int\_gateway.pp -i ext\_gateway.pp\\ Attempting to install module 'int\_gateway.pp':\\ Ok: return value of 0.\\ Attempting to install module 'ext\_gateway.pp':\\ Ok: return value of 0.\\ Committing changes:\\ libsepol.expand\_terule\_helper: conflicting TE rule for (unconfined\_t,\\ secure\_services\_exec\_t:process): old was ext\_gateway\_t, new is int\_gateway\_t\\ libsepol.expand\_module: Error during expand\\ libsemanage.semanage\_expand\_sandbox: Expand module failed\\ semodule: Failed!\\
}
\vspace{8mm}
 
\hspace{1mm} Celà se produit parce que les règles de type forcé ne permettent qu'un seul type par défaut pour une source et cible donnée. Dans la cas ci-dessus il y a 2 déclaration type\_transition avec la même source et cible, mais différents domaines par défaut. Le module ext\_gateway.conf a les déclarations suivantes:
 
{\ttfamily
allow unconfined\_t ext\_gateway\_t : process \{ transition \};\\ allow unconfined\_t secure\_services\_exec\_t : file \{ read execute getattr \};\\ allow ext\_gateway\_t secure\_services\_exec\_t : file \{ entrypoint \};\\ type\_transition unconfined\_t secure\_services\_exec\_t : process ext\_gateway\_t;\\
}
\vspace{8mm}
 
\hspace{1mm} et le module int\_gateway\_t a les déclarations suivantes:
 
{\ttfamily
allow unconfined\_t int\_gateway\_t : process \{ transition \};\\ allow unconfined\_t secure\_services\_exec\_t : file \{ read execute getattr \};\\ allow int\_gateway\_t secure\_services\_exec\_t : file \{ entrypoint \};\\ type\_transition unconfined\_t secure\_services\_exec\_t : process int\_gateway\_t;\\
}
\vspace{8mm}
 
\hspace{1mm}  Alors que les règles allow sont valides pour permettre les transitions, les 2 déclarations type\_transition ont des types par défaut différents (ou domaines cible), qui cassent la règle de type forcé.
\vspace{5mm} \\
 
 
\hspace{1mm}  Pour résoudre cela, il a été décidé:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Conserver la règle type\_transition pour le type par défaut de ext\_gateway\_t, et autoriser le processus serveur à être exécuté depuis unconfined\_t, en lançant simplement la commande depuis le prompts comme suit: \textbf{secure\_server 99999}}
\item[\hspace{1mm} 2.]{Utiliser la commande runcon pour s'assurer que la gateway interne se lance dans le domaine corecte en lançant runcon depuis le prompte comme suit: \textbf{runcon -t int\_gateway\_t -r message\_filter\_r secure\_server 1111}}
\end{description}
 
\hspace{1mm}  La commande runcom utilise libselinux pour vérifier le contexte courant et définir le nouveau contexte.
\vspace{5mm} \\
 
 
\hspace{1mm}  d'autres manières de résoudre ce problème sont:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Utiliser la commande runcon pour lancer les 2 gateway pour transiter dans leur domaine respectifs. Les déclarations type\_transition sont donc non requis.}
\item[\hspace{1mm} 2.]{Utiliser des noms différents pour les fichiers exécutables du serveur et s'assurer qu'ils ont un type différent}
\item[\hspace{1mm} 3.]{Implémenter la stratégie sur le modèle de la section templace macro.}
\end{description}
 
\vspace{1cm}{\huge Transition d'objet }
 
\
 
\hspace{1mm} Une transition d'objet se produit lorsqu'un nouvel objet nécessite un label différent de celui de son parent. Par exemple un fichier créé qui nécessite un label différent de son répertoire parent. la déclaration type\_transition permet de le faire:
 
{\ttfamily
type\_transition ext\_gateway\_t in\_queue\_t:file in\_file\_t;\\
}
\vspace{8mm}
 
\hspace{1mm} Les détails suivants d'une transition d'objet utilisée dans le module ext\_gateway.conf où par défaut, les fichiers sont labélisés in\_queue\_t quand ils sont créés par l'application gateway vu que ce label est attaché au répertoire parent:
 
{\ttfamily
ls -Za /usr/message\_queue/in\_queue\\ drwxr-xr-x root root unconfined\_u:object\_r:in\_queue\_t .\\ drwxr-xr-x root root system\_u:object\_r:unconfined\_t ..\\
}
\vspace{8mm}
 
\hspace{1mm} Cependant il est requis que les fichiers dans ce répertoire soient labélisés in\_file\_t. Pour celà les fichiers créé doivent être relabélisés dans in\_file\_t en utilisant un type\_transition:
 
{\ttfamily
type\_transition | source\_domain | target\_domain : object | default\_type;\\ type\_transition ext\_gateway\_t in\_queue\_t : file in\_file\_t;\\
}
\vspace{8mm}
 
\hspace{1mm}  Cette déclaration type\_transition status que lorsqu'un processus tournant dans le domaine ext\_gateway\_t (le domaine source) souhaite créer un objet fichier dans le répertoire qui est labélisé in\_queue\_t, le fichier devrait être relabélisé in\_file\_t si permis par la stratégie.
\vspace{5mm} \\
 
 
\hspace{1mm}  Cependant, comme décris plus haut, pour être capable de créer le fichier, les permissions minimum suivantes doivent être données dans la stratégie en utilisant les règle allow, où:
\vspace{5mm} \\
 
 
\hspace{1mm} 1. le domaine source a la permission d'ajouter des entrées fichier dans le répertoire: \\
\hspace{1mm} \textbf{allow ext\_gateway\_t in\_queue\_t : dir \{ write search add\_name );} \\
\hspace{1mm} 2. Le domaine source a la permission de créer des entrées fichiers: \\
\hspace{1mm} \textbf{allow ext\_gateway\_t in\_file\_t : file ( write create getattr );} \\
\hspace{1mm} 3. La stratégie peut ainsi s'assurer que les fichiers créé dans in\_queue sont relabélisés: \\
\hspace{1mm} \textbf{type\_transition ext\_gateway\_t in\_queue\_t : file in\_file\_t;} \\
\hspace{1mm} Un exemple de sortie d'un répertoire: \\
\hspace{1mm} \textbf{ls -Za /usr/message\_queue/in\_queue} \\
\hspace{1mm} drwxr-xr-x root root unconfined\_u:object\_r:in\_queue\_t . \\
\hspace{1mm} drwxr-xr-x root root system\_u:object\_r:unconfined\_t .. \\
\hspace{1mm} -rw-r--r-- root root unconfined\_u:object\_r:in\_file\_t Message-1 \\
\hspace{1mm} -rw-r--r-- root root unconfined\_u:object\_r:in\_file\_t Message-2 \\
 
\vspace{1cm}{\huge MLS et MCS }
 
\
 
\hspace{1mm}  Comme définis dans la section MAC et TE, SELinux supporte également MLS et MCS en ajoutant une entrée optionnelle level ou range dans le contexte de sécurité. Cette section donne une brève introduction à MLS et MCS.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le schéma ci-dessous montre un diagramme simple où les niveaux de sécurité représentent la classification des fichiers dans un serveur de fichier. Les niveaux de sécurité sont strictement hiérarchiques et conformes au modèle Bell-La \& Padula dans le fait qu'un processus (tournant au niveau Confidential) peut lire/écrire à son niveau courant, mais ne peut que lire dans les niveaux inférieurs ou seulement écrire dans les niveaux supérieurs.
\vspace{5mm} \\
 
 
\hspace{1mm}  Celà s'assure de la confidentialité vu que le processus peut copier un fichier au nieau secret, mais ne peut jamair relire son contenu sauf si le processus s'élève à ce niveau. Le processus ne peut pas écrire les fichiers à des niveaux inférieurs au niveau confidential.
\vspace{5mm} \\
 
 
{\includegraphics[]{../images/selinux07.png}}
 
\hspace{1mm}  Pour accomplir ce niveau de contrôle, les extensions MLS de SELinux utilisent les contraintes similaires à ceux décris dans la section contraintes des types forcés, excepté que la déclaration est appelée mlsconstrain.
\vspace{5mm} \\
 
 
\hspace{1mm}  Cependant, comme la vie n'est pas simple:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Les processus et objets peuvent avoir une plage qui représente les niveaux de sécurité faible et élevés}
\item[\hspace{1mm} 2.]{Le niveau de sécurité peut être plus complexe, en cela que c'est une sensibilité hiérarchique et 0 ou plusieurs catégories}
\item[\hspace{1mm} 3.]{Permettre à un processus d'accéder à un objet est géré par des règles de dominance appliqués aux niveaux de sécurité.}
\item[\hspace{1mm} 4.]{Les processus trustés peuvent avoir des privilèges qui les autorisent à bypasser les règles BLP.}
\item[\hspace{1mm} 5.]{Certains objets ne supportent pas les fonctions de lecture/écriture séparés vu qu'ils nécessitent de lire/répondre dans les ce cas comme les réseaux.}
\end{description}
 
\hspace{1mm}  Les sections qui suivent discutent du format d'un niveau de sécurité et de la plage, et la manière dont elles sont gérées par les mécanismes de contrainte dans SELinux en utilisant les règles de dominance.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Niveaux de sécurité }
 
\
 
\hspace{1mm}  Les éléments ci-dessous montrent les composants qui créent un niveau de sécurité et comment 2 niveaux de sécurité depuis une plage de pour le quatrième et options [:range].
\vspace{5mm} \\
 
 
\hspace{1mm}  Le niveau de sécurité consiste d'une sensibilité ou 0 ou plusieurs entrées catégories: \textbf{sensitivity [: category;...]}. Noter que SELinux utilise les niveaux, la sensibilité et la catégorisation dans les déclarations de langage, cependant les termes suivants peuvent également être utilisés: labels, classification, et compartiment.
\vspace{5mm} \\
 
 
\hspace{1mm}  Dans une plage, low, pour un processus, un sujet ou un objet constitue le niveau ou la sensibilité courante. SystemLow est le niveau ou la classification la plus faible pour le système. (pour SELinux, c'est généralement s0, noter qu'il n'y a pas de catégories).
\vspace{5mm} \\
 
 
\hspace{1mm}  Dans une plage, high, pour un processus ou un sujet est l'autorisation. Pour un objet, c'est la plage maximum. SystemHigh est le niveau ou la classification la plus haute (pour SELinux c'est généralement s15:c0,c255)
\vspace{5mm} \\
 
 
\hspace{1mm} Les composants suivants sont utilisés pour définir les niveaux de sécurité MLS/MCS dans le contexte de sécurité:
 
{\ttfamily
user:role:type:sensibilité\texttt{[}:catégorie,...\texttt{]} - sensibilité\texttt{[}:catégorie,...\texttt{]}\\
}
\vspace{8mm}
 
\hspace{1mm}  où:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} Sensibilité]{Les niveaux de sensibilité sont hiérarchiques avec (traditionnellement) s0 étend le plus faible. Ces valeurs sont définies en utilisant la déclaration sensitivity. Pour définir leur hiérarchie, la déclaration dominance est utilisée. Pour les systèmes MLS la sensibilité la plus haute est la dernière définie dans la déclaration dominance. Traditionnellement le maximum pour les système MLS est s15. Pour les système MCS il y a seulement une sensibilité définie, s0.}
\item[\hspace{1mm} Catégorie]{Les catégories sont optionnelles et forment une liste non-ordonnée et non-liées de compartiments. Ces valeurs sont définies en utilisant la déclaration category, où par exemple c0.c3 représente une plage et c0,c3,c7 représente une liste. Traditionnellement les valeurs sont entre c0 et c255.}
\item[\hspace{1mm} level]{Le niveau est une combinaison de valeurs de sensibilité et catégorie qui forment le niveau actuel de sécurité. Ces valeurs sont définies en utilisant une déclaration level.}
\end{description}
 
\vspace{1cm}{\huge Traduire les niveaux }
 
\
 
\hspace{1mm}  En écrivant des stratégie pour MS/MCS on utilise généralement une forme abbréviée tel que s0, s1, etc. pour représenter la sensibilité et c0, c1, etc. pour représenter les catégories. Cela permet de conserver de l'espace dans les attributs étendus des fichiers, et également en mémoire. Donc pour que ces labels puissent être représentés au format compréhensible, un service de traduction est fournis via le fichier setrans.conf qui est utilisé par le services mcstransd. Par exemple s0 = Unclassified, s15 = Top Secret et c0 = Finance, c100 = Spy Stories. La commande semanage peut être utilisée pour utiliser cette traduction.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Gérer les niveaux de sécurité via les règles de dominance }
 
\
 
\hspace{1mm}  Comme statué plus haut, autoriser un processu à accéder à un objet est géré par des règles de dominance appliqués aux niveaux de sécurité. Ces règle sont les suivantes:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} L1 domine L2]{Si la sensibilité de L1 est égal ou supérieur à la sensibilité de L2 et que les catégories de L1 sont les même ou un super-jeu des catégories de L2}
\item[\hspace{1mm} L2 domine L1]{Si la sensibilité de L1 est égal ou inférieur à la sensibilité de L2 et que les catégories de L1 sont un sous-jeu des catégories de L2}
\item[\hspace{1mm} L1 équivaut à L2]{Si la sensibilité de 1 et égal à L2 et les catégories de L1 et L2 sont les même.}
\item[\hspace{1mm} L1 est incomparable à L2]{Si les catégories de L1 et L2 ne peuvent être comparés.}
\end{description}
 
\hspace{1mm}  Pour illustrer l'utilisation de ces règles, la table ci-dessous liste les attributs de niveau de sécurité pour montrer des fichiers qui ont été labélisés comme s3:c0. Le processus qui accède à ces fichiers (ex: un éditeur) tourne avec une plage s0 - s3:c1.c5 et a accès aux fichiers en gras.
\vspace{5mm} \\
 
 
\hspace{1mm}  Vu que la déclaration dominance MLS est utilisée pour forcer la hiérarchie de sensibilité, les niveaux de sécurité suivent maintenant la séquence (faible = s0 à élevé = s3) avec les catégories étant des listes de compartiments. Pour autoriser le processus à accéder aux fichiers dans son scope et avec les règles de dominance, le processus sera contraint en utilisant la déclaration mlsconstrain.
\vspace{5mm} \\
 
 
{\includegraphics[]{../images/selinux08.png}}
 
{\includegraphics[]{../images/selinux09.png}}
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Pour autoriser write-up, le niveau source (l1) doit être dominé par le niveau cible (l2)}
\item[\hspace{1mm} 2.]{Pour autoriser read-down, le niveau source (l1) doit dominer le niveau cible (l2)}
\end{description}
 
\hspace{1mm}  Cependant, dans le monde réel la stratégie de référence MLS n'autorise pas le write-up sauf si le processus a un privilège spécial (en ayant le type de domaine ajouté à un attribut), bien qu'il autorise le read-down. Le défaut est d'utitilesr l1 et l2. Le fichier source policy/mls montre ces déclaration mlsconstrain.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Certification Common Criteria }
 
\
 
\hspace{1mm}  Bien que le processus de certification Common Criteria est au delà du scope de ce document, Il est à souligner que des versions de logiciel RedHat, tournant sur des plateformes hardware spécifiques avec SELinux/MLS ont passé le processus d'évaluation Common Criteria. Noter que pour l'évaluation et le déploiement de logiciel et hardware sont liés, quand une mise à jours est nécessaire, une mise à jours de la certifiation doit être obtenue.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Types de stratégie SELinux }
 
\
 
\hspace{1mm}  Cette section décris les différents types de stratégie. Le type de stratégie SELinux peut être décris de plusieurs manières.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Stratégie exemple }
 
\
 
\hspace{1mm}  La stratégie exemple est le nom utilisée pour décrir le source utilisé pour construire une stratégie monolitique produite par le NSA et désormais remplacé par le stratégie de référence.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Stratégie référence }
 
\
 
\hspace{1mm}  Le stratégie référence est le startégie standard utilisée pour construire des stratégies SELinux, et son but est de fournir une arborescence simple avec une documentation support qui peut être utilisé pour construire des stratégie pour différents cas tel que confiner des services importants, supporter MLS/MCS et bloquer les systèmes pour que tous les processus soient sous le contrôle de SELinux.
\vspace{5mm} \\
 
 
\hspace{1mm}  La stratégie référence est utilisée par toutes les distributions Linux, cependant, chaque distribution effectue des propres changements.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Fonctionnalité de stratégie basé sur le nom ou le type }
 
\
 
\hspace{1mm}  Généralement une stratégie est installée avec un nom donné tel que targeted, mls, refpolicy ou minimum qui tente de décrire ses fonctionnalités. Ce nom devient ainsi l'entrée dans:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Le répertoire pointant à l'emplacement de la stratégie (ex: si le nom est targeted, la stratégie est installée dans /etc/selinux/targeted)}
\item[\hspace{1mm} 2.]{L'entrée SELINUXTYPE dans /etc/selinux/config quand c'est la stratégie active (ex: si le nom est targeted, l'entrée est SELINUXTYPE=targeted).}
\end{description}
 
\vspace{1cm}{\huge Stratégie Monolitique }
 
\
 
\hspace{1mm}  Une stratégie monolitique est une stratégie SELinux qui est compilée depuis un fichier source appelé par convention policy.conf. Il n'utilise pas les déclaration de module chargeable et est prévu pour les systèmes embarqués.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Stratégie à module chargeable }
 
\
 
\hspace{1mm}  L'infrastructure à module chargeable permet de gérer une stratégie sur une base modulaire, il y a un module de stratégie de base qui contient tous les composants du corp de la stratégie, et 0 ou plusieurs modules qui peuvent être chargés et déchargés si requis. Il y a plusieurs composants qui forment l'infrastructure:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Le source de la stratégie qui est construite pour une stratégie modulaire avec un module de base et des modules chargeables optionnels}
\item[\hspace{1mm} 2.]{Des utilitaires pour compiler et lier les modules et les placer dans un magasin de stratégie}
\item[\hspace{1mm} 3.]{Des utilitaires pour gérer les modules et les fichiers de configuration associés dans le magasin de stratégie}
\end{description}
 
\vspace{1cm}{\huge Stratégie optionnelle }
 
\
 
\hspace{1mm}  L'infrastructure de stratégie à module supporte également une déclaration optionnelle qui permet de définir des règsles qui sont activées eulement dans la stratégie binaire une fois les conditions satisfaites.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Stratégie conditionnelle }
 
\
 
\hspace{1mm}  Les stratégie conditionnelles peuvent être implémentées dans des stratégies monolitiques ou à module et permet d'activer des parties de la stratégie en fonction de l'état d'un flag en temps-réel. Les flags sont maintenus dans le kernel et peuvent être changés avec setsebool.
\vspace{5mm} \\
 
 
\hspace{1mm}  Les déclaration de langage de stratégie conditionnelle sont des déclaration bool qui définissent l'identifiant de flag et son status initial, et la déclaration if qui permet à certaines règles d'être exécutées en fonction de l'état des valeur booléennes.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Stratégie binaire }
 
\
 
\hspace{1mm}  Également connu sous le nom de stratégie kernel, c'est le fichier de stratégie qui est chargé dans le kernel et est localisé à /etc/selinux/<SELINUXTYPE>/policy/policy.<version>.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Versions de stratégie }
 
\
 
\hspace{1mm}  SELinux a une base de stratégie (définie dans libsepol) qui décris le format des données gérée dans une stratégie binaire, cependant, si de nouvelles fonctionnalités sont ajoutées à SELinux, il peut y avoir un changement dans la base. sestatus affiche la version maximum supportée par le kernel.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Mode permissif et forcé }
 
\
 
\hspace{1mm}  SELinux a 3 modes d'opération majeurs:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} Enforcing]{SELinux impose la stratégie chargée}
\item[\hspace{1mm} Permissive]{SELinux charge la stratégie, mais ne l'impose pas. Généralement utilisé pour les tests}
\item[\hspace{1mm} Disabled]{SELinux n'est pas activé.}
\end{description}
 
\hspace{1mm}  Ces flags sont définis dans /etc/selinux/config. Il y a une autre méthode pour exécuter des domaines spécifique en mode permissif en utilisant la déclaration permissive. Cela peut être utilisé dans un module utilisateur ou semanage génère le module approprié et le charge en utilisant l'exemple suivant: \textbf{semanage permissive -a unconfined\_t}
\vspace{5mm} \\
 
 
\hspace{1mm}  Il est également possible de définir un mode permissif dans le gestionnaire d'objet userspace en utilisant libselinux. sestatus affiche le mode courant, cependant, il n'affiche pas le domaine individuel ou les modes du gestionnaire d'objet.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Auditer les évènements SELinux }
 
\
 
\hspace{1mm}  Pour SELinux il y a 2 types principaux d'évènements d'audit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Les évènement AVC - Ils sont générés par le sous-système AVC en résultat à des accès refusés, ou quand des évènements spécifique sont demandés.}
\item[\hspace{1mm} 2.]{Évènements d'applications - Ils sont générés par les services kernel SELinux et les applications compatibles SELinux.}
\end{description}
 
\hspace{1mm}  Les messages d'évènement et d'audit sont généralement stockés dans un de ces logs:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Le évènement SELinux du boot kernel sont loggés dans /var/log/dmesg}
\item[\hspace{1mm} 2.]{/var/log/messdages contient les messages générés par SELinux avant que le système d'audit soit chargé}
\item[\hspace{1mm} 3.]{/var/log/audit/audit.log contient les évènements qui prennent place une fois le service d'audit chargé.}
\end{description}
 
\vspace{1cm}{\huge Notes }
 
\
 
\begin{description} \normalsize
\item[\hspace{1mm} a)]{Il n'est pas obligatoire pour les applications SELinux d'auditer les évènements ni de les logger.}
\item[\hspace{1mm} b)]{Le format des messages d'audit n'a pas besoin de se conformer à un format, cependant, si possible les applications devraient utiliser la fonction audit\_log\_user\_avc\_message(3)}
\item[\hspace{1mm} c)]{Le fonctions de librairie SELinux affichent des messages également sur stderr par défaut. Cependant celà peut être changé avec selinux\_set\_callback(3).}
\end{description}
 
\vspace{1cm}{\huge Évènements d'audit AVC }
 
\
 
\hspace{1mm}  Cette section décris le format général des messages d'audit AVC dans audit.log.
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} type]{type peut être AVC pour les évènements kernel, ou USER\_AVC pour les évènement des gestionnaires d'objet userspace. Une fois l'évènement AVC loggé, le type SYSCALL peut suivre et contient des informations supplémentaires}
\item[\hspace{1mm} msg]{Contient le mot clé 'audit' avec un numéro de référence}
\item[\hspace{1mm} avc]{Soit denied soit granted}
\item[\hspace{1mm} pid|comm]{Si c'est une tâche, log le pid et le nom de l'exécutable}
\item[\hspace{1mm} capability]{Si c'est un évènement de capability, log l'identifiant}
\item[\hspace{1mm} path|name|dev|ino]{Si c'est en évènement de système de fichier, log les informations spécifique}
\item[\hspace{1mm} laddr|lport|faddr|fport]{Si c'est un évènement socket, log les adresses/port source/destination}
\item[\hspace{1mm} path]{Si c'est un évènement de fichier socket, log le chemin}
\item[\hspace{1mm} saddr|src|daddr|dest|netif]{Si un évènement réseau, log les adresses/port source/destination}
\item[\hspace{1mm} sauid|hostname|addr|terminal]{Identifiant d'association de sécurité IPSec}
\item[\hspace{1mm} resid|restype]{Type et ID de ressource X-Windows}
\item[\hspace{1mm} scontext]{Le contexte de sécurité de la ressource ou sujet}
\item[\hspace{1mm} tcontext]{Le contexte de sécurité de la cible ou objet}
\item[\hspace{1mm} tclass]{La classe objet de la cible ou objet}
\end{description}
 
\vspace{1cm}{\huge Évènements d'audit SELinux général }
 
\
 
\hspace{1mm}  Cette section montre une sélection d'évènements d'audits de service non AVC pris depuis audit.log. Pour une liste d'entrée "type=" valides, les fichiers include suivant devraient être consultés: include/libaudit.h et include/linux/audit.h.
\vspace{5mm} \\
 
 
\hspace{1mm}  Noter qu'il peut y avoir plusieurs évènements générés pour le même évènement. Par exemple, le serveur de sécurité kernel génère une évènement MAC\_POLICY\_LOAD pour indiquer que la stratégie a été rechargée, mais chaque gestionnaire d'objet userspace peut également générer un USER\_MAC\_POLICY\_LOAD pour indiquer qu'il a également traité l'évènement.
\vspace{5mm} \\
 
 
\hspace{1mm} MAC\_POLICY\_LOAD, USER\_MAC\_POLICY\_LOAD - ces évènements sont générés quand la stratégie est rechargée:
 
{\ttfamily
type=MAC\_POLICY\_LOAD msg=audit(1336662937.117:394): policy loaded auid=0 ses=2\\ type=SYSCALL msg=audit(1336662937.117:394): arch=c000003e syscall=1 success=yes exit=4345108 a0=4 a1=7f0a0c547000 a2=424d14 a3=7fffe3450f20 items=0 ppid=3845 pid=3848 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=2 comm="load\_policy" exe="/sbin/load\_policy" subj=unconfined\_u:unconfined\_r:load\_policy\_t:s0-s0:c0.c1023 key=(null)\\ type=USER\_MAC\_POLICY\_LOAD msg=audit(1336662938.535:395): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system\_u:system\_r:xserver\_t:s0-s0:c0.c1023 msg='avc: received policyload notice (seqno=2) : exe="/usr/bin/Xorg" sauid=0 hostname=? addr=? terminal=?'\\
}
\vspace{8mm}
 
\hspace{1mm} MAC\_STATUS - Généré quand le mode SELinux est changé:
 
{\ttfamily
type=MAC\_STATUS msg=audit(1336836093.835:406): enforcing=1 old\_enforcing=0\\ auid=0 ses=2\\ type=SYSCALL msg=audit(1336836093.835:406): arch=c000003e syscall=1 success=yes exit=1 a0=3 a1=7fffe743f9e0 a2=1 a3=0 items=0 ppid=2047 pid=5591 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="setenforce" exe="/usr/sbin/setenforce" subj=unconfined\_u:unconfined\_r:unconfined\_t:s0-s0:c0.c1023 key=(null)\\
}
\vspace{8mm}
 
\hspace{1mm} MAC\_CONFIG\_CHANGE - Généré quand setsebool a été lancé pour changer un booléen.
 
{\ttfamily
type=MAC\_CONFIG\_CHANGE msg=audit(1336665376.629:423): bool=domain\_paste\_after\_confirm\_allowed val=0 old\_val=1 auid=0 ses=2\\ type=SYSCALL msg=audit(1336665376.629:423): arch=c000003e syscall=1 success=yes exit=2 a0=3 a1=7fff42803200 a2=2 a3=7fff42803f80 items=0 ppid=2015 pid=4664 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="setsebool" exe="/usr/sbin/setsebool" subj=unconfined\_u:unconfined\_r:setsebool\_t:s0-s0:c0.c1023 key=(null)\\
}
\vspace{8mm}
 
\hspace{1mm} MAC\_UNLBL\_STCADD - Généré quand un label statique non-mappé est ajouté
 
{\ttfamily
type=MAC\_UNLBL\_STCADD msg=audit(1336664587.640:413): netlabel: auid=0 ses=2 subj=unconfined\_u:unconfined\_r:unconfined\_t:s0-s0:c0.c1023 netif=lo src=127.0.0.1 sec\_obj=system\_u:object\_r:unconfined\_t:s0-s0:c0,c100 res=1\\ type=SYSCALL msg=audit(1336664587.640:413): arch=c000003e syscall=46 success=yes exit=96 a0=3 a1=7fffde77f160 a2=0 a3=666e6f636e753a72 items=0 ppid=2015 pid=4316 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="netlabelctl" exe="/sbin/netlabelctl" subj=unconfined\_u:unconfined\_r:unconfined\_t:s0-s0:c0.c1023 key=(null)\\
}
\vspace{8mm}
 
\hspace{1mm} SELINUX\_ERR - Généré par le serveur de sécurité kernel suite à des privilège de anon-webapp\_t supérieur à celui donné au processus qui a lancé le thread
 
{\ttfamily
type=SELINUX\_ERR msg=audit(1311948547.151:138): op=security\_compute\_av reason=bounds scontext=system\_u:system\_r:anon\_webapp\_t:s0-s0:c0,c100,c200 tcontext=system\_u:object\_r:security\_t:s0 tclass=dir perms=ioctl,read,lock\\ type=SELINUX\_ERR msg=audit(1311948547.151:138): op=security\_compute\_av reason=bounds scontext=system\_u:system\_r:anon\_webapp\_t:s0-s0:c0,c100,c200 tcontext=system\_u:object\_r:security\_t:s0 tclass=file perms=ioctl,read,write,getattr,lock,append,open\\
}
\vspace{8mm}
 
\hspace{1mm} Généré par le serveur de sécurité kernel quand une application compatible SELinux tente d'utiliser setcon pour créer un nouveau thread
 
{\ttfamily
type=SELINUX\_ERR msg=audit(1311947138.440:126): op=security\_bounded\_transition result=denied oldcontext=system\_u:system\_r:httpd\_t:s0-s0:c0.c300 newcontext=system\_u:system\_r:anon\_webapp\_t:s0-s0:c0,c100,c200\\ type=SYSCALL msg=audit(1311947138.440:126): arch=c000003e syscall=1 success=no exit=-1 a0=b a1=7f1954000a10 a2=33 a3=6e65727275632f72 items=0 ppid=3295 pid=3473 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system\_u:system\_r:httpd\_t:s0-s0:c0.c300 key=(null)\\
}
\vspace{8mm}
 
\hspace{1mm} USER\_ROLE\_CHANGE - newrole(1) a été utilisé pour définir un nouveau rôle qui n'est pas valide
 
{\ttfamily
type=USER\_ROLE\_CHANGE msg=audit(1336837198.928:429): pid=0 uid=0 auid=0 ses=2 subj=unconfined\_u:unconfined\_r:unconfined\_t:s0-s0:c0.c1023 msg='newrole: old-context=unconfined\_u:unconfined\_r:unconfined\_t:s0-s0:c0.c1023 new-context=?: exe="/usr/bin/newrole" hostname=? addr=? terminal=/dev/pts/0 res=failed'\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Support de la poly-instanciation }
 
\
 
\hspace{1mm}  GNU/Linux supporte la poly-instanciation des répertoires qui peuvent être utilisé par SELinux via PAM. La poly-instanciation des objets est également supporté pour les sélections X-Windows. Noter que les sockets ne sont pas encore supportés. Pour clarifier le support de la polyinstanciation:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{SELinux a des fonctions libselinux et une règle de stratégie pour supporter la poly-instanciation}
\item[\hspace{1mm} 2.]{La poly-instanciation des répertoires est une fonction de GNU/Linux}
\item[\hspace{1mm} 3.]{La poly-instanciation des sélections X-Windows et des propriétés est une fonction du gestionnaire d'objet XSELinux et le support du service XACE}
\end{description}
 
\vspace{1cm}{\huge Objects poly-instanciés }
 
\
 
\hspace{1mm}  Déterminer un contexte poly-instancié pour un objet est supporté par SELinux en utilisant la déclaration type\_member et les fonctions avc\_compute\_member et security\_compute\_member. Ce n'est pas limité à des classes d'objets spécifique, cependant seul les objets dir, x\_selection et x\_property sont actuellement supportés.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Support de la poly-instanciation dans PAM }
 
\
 
\hspace{1mm}  PAM supporte la poly-instanciation (namespaces) des répertoires à la connexion en utilisant les services d'arborescence partagée/espaces de noms disponibles dans GNU/Linux (voir namespace.conf) Noter que PAM et les services d'espace de nom sont compatibles SELinux.
\vspace{5mm} \\
 
 
\hspace{1mm}  L'installation par défaut de F-20 n'active pas les répertoires poly-instanciés par défaut, cependant cette section montre la configuration requise pour activer cette fonctionnalité et quelques exemples.
\vspace{5mm} \\
 
 
\hspace{1mm}  Pour implémenter les répertoires poly-instanciés PAM exige que les fichiers suivants soient configurés:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Une entrée pour le module pam\_namespace. F-20 a déjà ces entrées dans /etc/pam.d/gdm-password.}
\item[\hspace{1mm} 2.]{Les entrées sont ajoutées dans /etc/security/namespace.conf et définissent les répertoires à poly-instancier par PAM.}
\end{description}
 
\hspace{1mm}  Une fois ces fichiers configurés et qu'un utilisateur se log, pam\_namespace départage l'espace de nom cournat de son parent et monte les espaces de nom en accord avec les règles définies dans namespace.conf. F-20 inclus également le script /etc/security/namespace.init. qui est utilisé pour initialiser l'espace de nom chaque fois qu'une nouvelle instance de répertoire est définis. Ce script reçois 4 paramètres: le chemin du répertoire poly-instancié, le chemin de l'instance du répertoire, un flag pour indiquer si une nouvelle instance, et un nom d'utilisateur. Si une nouvelle instance est définie, les permissions du répertoire sont définis et restorecon(8) est lancé pour définir le contexte de fichier.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Fichier de configuration namespace.conf }
 
\
 
\hspace{1mm} Chaque ligne dans namespace.conf est formaté comme suit: \\
\hspace{1mm} \textbf{polydir instance\_prefix method list\_of\_uids} \\
\hspace{1mm} où: \\
 
\begin{description} \normalsize
\item[\hspace{6mm} polydir]{Chemin absolu du répertoire à poly-instancier. \$USER et \$HOME sont remplacés}
\item[\hspace{6mm} instance\_prefix]{Un préfixe utilisé pour construire le chemin pour le répertoire poly-instancié. \$USER et \$HOME sont remplacés}
\item[\hspace{6mm} method]{Détermine a méthode de la poly-instanciation:}
\end{description}
 
\begin{description} \normalsize
\item[\hspace{12mm} user]{La poly-instanciation est basée sur les noms d'utilisateur}
\item[\hspace{12mm} level]{La poly-instanciation est basée sur le nom d'utilisateur et le niveau MLS}
\item[\hspace{12mm} context]{La poly-instanciation est basée sur le nom d'utilisateur et le contexte de sécurité}
\end{description}
 
\hspace{6mm}  Liste de noms d'utilisateurs qui n'ont pas de répertoires poly-instanciés. Si vide, tous les utilisateurs poly-instanciés. Si la liste est précédée par '-', seul les utilisateurs dans la liste ont des répertoires poly-instanciés.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Exemple de configuration }
 
\
 
\hspace{1mm}  Cette section montre 2 exemple de configuration namespace.conf, le premier utilise la méthode user, et l'autre context. Noter que tant que la poly-instanciation est activée, les noms de chemins complet ne sont pas visible, c'est seulement quand la poly-instanciation est désactivée que les répertoires deviennent visible.
\vspace{5mm} \\
 
 
\hspace{1mm} Exemple 1 - method=user:
 
{\ttfamily
\#polydir instance-prefix method list\_of\_uids\\ /tmp /tmp-inst/ user root,adm\\ /var/tmp /var/tmp/tmp-inst/ user root,adm\\ \$HOME \$HOME/\$USER.inst/ user\\
}
\vspace{8mm}
 
\hspace{1mm} Se connecter en tant qu'utilisateur normal. Le processus PAM va construire les répertoires poly-instanciés suivant:
 
{\ttfamily
\# /tmp\\ /tmp/tmp-inst/myuser\\ \# /var/tmp\\ /var/tmp/tmp-inst/myuser\\ \# \$HOME\\ /home/myuser/myuser.inst/myuser\\
}
\vspace{8mm}
 
\hspace{1mm} Exemple 2 - method=context
 
{\ttfamily
\#polydir instance-prefix method list\_of\_uids\\ /tmp /tmp-inst/ context root,adm\\ /var/tmp /var/tmp/tmp-inst/ context root,adm\\ \$HOME \$HOME/\$USER.inst/ context\\
}
\vspace{8mm}
 
\hspace{1mm} Se connecter en tant qu'utilisateur normal. Le processus PAM va construire les répertoires poly-instanciés suivant:
 
{\ttfamily
\# /tmp\\ /tmp/tmp-inst/unconfined\_u:unconfined\_r:unconfined\_t\_myuser\\ \# /var/tmp\\ /var/tmp/tmp-inst/unconfined\_u:unconfined\_r:unconfined\_t\_myuser\\ \# \$HOME\\ /home/myuser/myuser.inst/unconfined\_u:unconfined\_r:unconfined\_t\_myuser\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Support dans la stratégie référence }
 
\
 
\hspace{1mm}  Les modules files.te et files.if supportent la poly-instanciation. Il y a également un booléen allow\_polyinstanciation qui peut être utilisé pour activer cette fonctionnalité durant le login. Défaut: false.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Processus de login PAM }
 
\
 
\hspace{1mm}  Les application utilisées pour fournir des services de login (comme gdm ou ssh) utilisent PAM pour fournir les services suivants:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} Gestion de compte:]{Ce service gère les services tels que l'expiration des mots de passe, et les services de login autorisés}
\item[\hspace{1mm} Gestion de l'authentification]{Authentifie l'utilisateur ou le sujet et définis les accréditifs}
\item[\hspace{1mm} Gestion des mots de passe]{Gère les mises à jours de mot de passe}
\item[\hspace{1mm} Gestion de session]{Gère les service qui doivent être invoqués avant que le processus de login se complète et/ou quand le processus de login de termine.}
\end{description}
 
\hspace{1mm} Il y a également des fichiers de configuration PAM liés à SELinux dans la section file de /etc/security/sepermit.conf. Les services core sont fournis par PAM, cependant d'autres moules peuvent être écris pour gérer les services spécifiques tel que le support pour SELinux. Les modules SELinux utilisent libseliinux pour obtenir la configuration: \\
 
\begin{description} \normalsize
\item[\hspace{1mm} pam\_selinux\_permit.so]{Autorise à des utilisateurs prédéfinis la capacité de se logger sans fournir de mot de passe}
\item[\hspace{1mm} pam\_selinux.so open]{Définis un contexte de sécurité pour l'utilisation au login.}
\item[\hspace{1mm} pam\_selinux.so close]{Réinitialise le contexte des programme login au contexte par défaut}
\end{description}
 
\vspace{1cm}{\huge LSM et SELinux }
 
\
 
\hspace{1mm}  LSM est le framework de sécurité Linux qui autorise à des mécanisme de contrôle d'accès tier d'être liés dans le kernel GNU/Linux. Actuellement il y a 5 services qui utilisent LSM:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{SElinux}
\item[\hspace{1mm} 2.]{AppArmor}
\item[\hspace{1mm} 3.]{SMACK}
\item[\hspace{1mm} 4.]{Tomoyo}
\item[\hspace{1mm} 5.]{Yama}
\end{description}
 
\hspace{1mm}  L'idée de base derrière LSM est de:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{Insérer des hooks de fonction de sécurité et des structures de données de sécurité dans les divers services kernel.}
\item[\hspace{1mm} -]{Autoriser l'enregistrement et l'initialisatio des services pour les modules tiers de sécurité}
\item[\hspace{1mm} -]{Les attributs de sécurité de processus sont disponibles aux services userspace en étendant le système de fichier /proc avec un espace de nom de sécurité}
\item[\hspace{1mm} -]{Supporter des systèmes de fichier qui utilisent les attributs étendus}
\item[\hspace{1mm} -]{Consolider les capacités Linux dans un module optionnel}
\end{description}
 
\hspace{1mm}  Il devrait être noté que LSM ne fournis aucun service de sécurité, seulement les hooks et structures pour supporter des modules tiers. S'il n'y a pas de module tiers chargé, les capacités deviennent le module par défaut autorisant le modèle DAC standard
\vspace{5mm} \\
 
 
\hspace{1mm} Les services kernel où LSM implémente les hooks et structures sont:
 
{\ttfamily
exécution de programme\\ opérations de fichier\\ Réseaux de domaine Unix\\ Opérations de gestion de clé\\ Sémaphores\\ Syslog\\ Opérations de système de fichier\\ Opérations sur les tâches\\ Opérations sur les sockets\\ Opérations IPC\\ Capability\\ Audit\\ Opérations sur les inodes\\ Messagerie Netlink\\ Opérations XFRM\\ Segments mémoire\\ Sysctl\\
}
\vspace{8mm}
 
\hspace{1mm}  Fichiers /proc/self/attr/ utilisé par les services kernel et libselinux:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} current]{(-rw-rw-rw) - Contient le contexte de sécurité du processus}
\item[\hspace{1mm} exec]{(-rw-rw-rw) - Définis le contexte de sécurité pour le prochain appel exec}
\item[\hspace{1mm} fscreate]{(-rw-rw-rw) - Définis le contexte de sécurité des nouveaux fichiers créés}
\item[\hspace{1mm} keycreate]{(-rw-rw-rw) - Définis le contexte de sécurité pour les clés qui sont en cache dans le kernel}
\item[\hspace{1mm} prev]{(-r--r--r-) - Contient le précédent contexte de sécurité}
\item[\hspace{1mm} sockcreate]{(-rw-rw-rw) - Définis le contexte de sécurité pour les nouveaux sockets créés}
\end{description}
 
\vspace{1cm}{\huge Support réseau }
 
\
 
\hspace{1mm}  SELinux supporte les types suivans de label réseau:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} Label interne]{C'est où les objets réseaux sont labélisés et gérés en interne dans une seule machine: SECMARK et NetLabel}
\item[\hspace{1mm} Réseau labélisé]{Lorsque les labels sont passé aux systèmes distant où ils peuvent être interprétés: IPSec et CIPSO}
\end{description}
 
\hspace{1mm}  Il y a 2 options de capability de stratégie qui peuvent être définis dans la stratégie en utilisant la déclaration policycap qui affecte la configuration réseau:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} network\_peer\_controls]{Toujours activé dans la stratégie référence}
\item[\hspace{1mm} always\_use\_network]{Cette capacité est normalement à false. À true, SECMARK et NetLabel sont toujours activés même s'il n'y a pas de règles configurés. Celà force la vérification de la classe packet pour protéger le système.}
\end{description}
 
\hspace{1mm}  Les paramètres de capability de stratégie sont disponible en userspace via les systèmes de fichiers SELinux. Pour supporter le label paire et CIPSO, les outils NetLabel doivent être installés (package netlabel\_tools)
\vspace{5mm} \\
 
 
\hspace{1mm}  Pour supporter IPSec labélisé, les outils IPSec doivent être installés (package ipsec-tools)
\vspace{5mm} \\
 
 
\hspace{1mm}  Il est également possible d'utiliser un service IPSec labélisé alternatif, LibreSwan
\vspace{5mm} \\
 
 
\hspace{1mm}  Il est important de noter que le kernel doit être configuré pour supporter ces services. Le package iproute a la commande de statistique socket ss(8) qui affiche le contexte SELinux des processus réseaux et les sockets réseaux. Noter que les contextes sockets sont pris depuis les inodes associés au socket et non de la structure socket kernel.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge SECMARK }
 
\
 
\hspace{1mm}  SECMARK utilise le framework NetFilter du kernel. NetFilter inspecte automatiquement tous les paquets entrants et sortants et peut placer des contrôles dans les interfaces, les adresse IP et ports avec un suivi de connexion. L'extension SECMARK permet d'ajouter des contextes de sécurité aux paquets (SECMARK) ou aux session (CONNSECMARK).
\vspace{5mm} \\
 
 
\hspace{1mm}  Le framework NetFilter inspecte et tag les paquets avec des labels tel que définis dans iptables puis utilise le framework de sécurité (ex: SELinux) pour forcer les règles de stratégie. La structure de base est comme suit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{Un table appelée 'security table' est utilisée pour définir les paramètres qui identifient et marque les paquets qui peuvent ainsi être suivis à mesure que le paquet voyage dans le sous-système réseaux. Ces marques sont appelées SECMARK et CONNSECMARK.}
\item[\hspace{1mm} -]{Un SECMARK est placé sur un paquet s'il matche une entrée dans la table de sécurité qui applique un label qui peut ensuite être utilisé pour forcer la stratégie dans le paquet.}
\item[\hspace{1mm} -]{Un CONNSECMARK maque tous les paquets dans une session avec le label approprié qui peut ensuite être utilisé pour forcer la stratégie.}
\end{description}
 
\hspace{1mm} Exemple d'entrée dans la table security. Marquer tous les paquets: \\
\hspace{1mm} \textbf{iptables -t security -A INPUT -i -lo -p tcp -d 127.0.0.0/8 -j SECMARK --selctx system.user:object\_r:msg\_filter.default\_packet:s0} \\
\hspace{1mm} Ces règles remplacent le contexte précédent avec la gateway interne ou externe si le port 9999 ou 1111 est trouvé: \\
\hspace{1mm} \textbf{iptables -t security -A INPUT -i lo -p tcp --dport 9999 -j SECMARK --selctx system.user:object\_r:msg\_filter.ext\_gateway.packet:s0} \\
\hspace{1mm} \textbf{iptables -t security -A INPUT -i lo -p tcp --sport 9999 -j SECMARK --selctx system.user:object\_r:msg\_filter.ext\_gateway.packet:s0} \\
\hspace{1mm} \textbf{iptables -t security -A INPUT -i lo -p tcp --dport 1111 -j SECMARK --selctx system.user:object\_r:msg\_filter.int\_gateway.packet:s0} \\
\hspace{1mm} \textbf{iptables -t security -A INPUT -i lo -p tcp --sport 1111 -j SECMARK --selctx system.user:object\_r:msg\_filter.int\_gateway.packet:s0} \\
\hspace{1mm} \textbf{iptables -t security -A INPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK --save} \\
\hspace{1mm} \# Flux de sortie \\
\hspace{1mm} \textbf{iptables -t security -A OUTPUT -o lo -p tcp -d 127.0.0.0/8 -j SECMARK --selctx system.user:object\_r:msg\_filter.default\_packet:s0} \\
\hspace{1mm} \textbf{iptables -t security -A OUTPUT -i lo -p tcp --dport 9999 -j SECMARK --selctx system.user:object\_r:msg\_filter.ext\_gateway.packet:s0} \\
\hspace{1mm} \textbf{iptables -t security -A OUTPUT -i lo -p tcp --sport 9999 -j SECMARK --selctx system.user:object\_r:msg\_filter.ext\_gateway.packet:s0} \\
\hspace{1mm} \textbf{iptables -t security -A OUTPUT -i lo -p tcp --dport 1111 -j SECMARK --selctx system.user:object\_r:msg\_filter.int\_gateway.packet:s0} \\
\hspace{1mm} \textbf{iptables -t security -A OUTPUT -i lo -p tcp --sport 1111 -j SECMARK --selctx system.user:object\_r:msg\_filter.int\_gateway.packet:s0} \\
\hspace{1mm} \textbf{iptables -t security -A OUTPUT -m state --state ESTABLISHED,RELATED -j CONNSECMARK --save} \\
 
\vspace{1cm}{\huge NetLabel - Fallback labeling }
 
\
 
\hspace{1mm}  le labeling peut optionnellement être implémenté dans un système si IPSec ou CIPSO labelisé n'est pas utilisé (falback labeling). Si IPSEC ou CIPSO labelisé est utilisé, il a précédence. Le contrôle du paire réseau a été étendu pour supporter une classe object additionnelles 'peer' qui est activé par défaut dans la stratégie F-20 si network\_peer\_controls dans /sys/fs/selinux/policy\_capabilities est à 1.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge NetLabel - CIPSO }
 
\
 
\hspace{1mm}  Pour permettre de passer des niveaux de sécurité dans un réseau entre des systèmes MLS, Le protocole CIPSE est utilisé. C'est définis dans draft-ietf-cipso-ipsecurity-01. Le protocole définis comment les labels de sécurité sont encodés dans l'en-tête IP.
\vspace{5mm} \\
 
 
\hspace{1mm}  Noter que seul le composant de niveau du contexte de sécurité est passé sur le réseau. L'exception est le mode loopback. Le protocole est implémenté par le service NetLabel et peut être utilisé par d'autres modules de sécurité qui utilisent l'infrastructure LSM. L'implémentation NetLabel supporte:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{1 bit de type de tag qui autorise un maximum de 256 niveaux et 240 catégories}
\item[\hspace{1mm} 2.]{Une option non-traductible où les labels sont passés depuis/vers les systèmes de manière inchangée.}
\item[\hspace{1mm} 3.]{Une option de traduction où la sensibilité et la catégories peuvent être mappés pour les systèmes qui ont des définitions différentes.}
\end{description}
 
\vspace{1cm}{\huge IPsec labélisé }
 
\
 
\hspace{1mm}  IPSec labélisé a été construit dans les service IPSec GNU/Linux. La figure ci-dessous montre les composants de base qui forment le service basé sur les outils IPSec généralement utilisés pour chiffrer un tunnel entre 2 machines ou une session de transport chiffré. Les extensions décrive comment le contexte de sécurité est configuré et négocié entre les 2 systèmes (appelé Associations de Securité (SA) dans la terminologie IPSec).
\vspace{5mm} \\
 
 
{\includegraphics[]{../images/selinux10.png}}
 
\hspace{1mm}  Basiquement il se produit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{La base de stratégie de sécurité (SPD) définis les caractéristiques de communication sécurisé à utiliser entre les 2 systèmes. C'est complété en utilisant setkey}
\item[\hspace{1mm} 2.]{Le SA a ses paramètres de configuration tel que les protocoles utilisé pour sécuriser les paquets, les algorithmes de chiffrement et la durée de validité des clés dans la base d'association de sécurité (SAD). Pour IPSec labélisé le contexte de sécurité est également définis dans SAD. Les SA peuvent être négociés entre les 2 systèmes en utilisant racoon ou pluto qui vont automatiquement populer SAD et manuellement avec setkey.}
\item[\hspace{1mm} 3.]{Une fois les SA négociés et validés, le lien devrait être actif.}
\end{description}
 
\hspace{1mm}  Noter que ces SA sont unidirectionnels, ainsi quand 2 systèmes communiquent, un système aura un SA. SAout pour traiter les paquets sortant, et un autre SAin pour traiter les paquets entrants. L'autre système devrat également créer 2 SA pour traiter ses paquets.
\vspace{5mm} \\
 
 
\hspace{1mm}  Chaque SA partage les même paramètres cryptographiques tels que les clés et protocoles ESP et AH.
\vspace{5mm} \\
 
 
\hspace{1mm}  La classe objet utilisée pour l'association d'un SA est 'association' et les permissions disponibles comme suit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} polmatch]{Matche le contexte SPD (-ctx) à un domaine SELinux (qui est contenu dans l'entrée -ctx SAD)}
\item[\hspace{1mm} recvfrom]{Reçu depuis une association IPSec}
\item[\hspace{1mm} sendto]{Envoyé à une association IPSec}
\item[\hspace{1mm} setcontext]{Définis le contexte d'une association IPSec à la création.}
\end{description}
 
\hspace{1mm}  En lançant IPSec labélisé il est recommandé que les systèmes utilisent le même type/version de stratégie pour éviter tout problème.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Exemples de configuration }
 
\
 
\hspace{1mm}  Il y a 2 solutions disponibles:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} Outils IPSec]{- setkey et racoon}
\item[\hspace{1mm} LibreSwan]{- ipsec et pluto}
\end{description}
 
\hspace{1mm}  Tous fonctionnent de la même manière mais utilisent différents fichiers de configuration. Le point qu'ils ont en commun est qu'ils démarrent une session en utilisant IKE, setkey doit être utilisé pour initialiser les labels dans la SPD dans chaque machine
\vspace{5mm} \\
 
 
\hspace{1mm}  Un autre point à noter est que si racoon et pluto sont interopérables, les valeurs d'attributs d'association de sécurité sont différents:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{racoon a cette valeur à 10}
\item[\hspace{1mm} -]{pluto est configurable avec par défaut 32001. Pour intéropérer avec racoon, ipsec.conf doit avoir: \textbf{secctx\_attr\_value = 10}}
\end{description}
 
\hspace{1mm}  L'exemple suivant montre la configuration setkey commune pour définir les entrées SPD et en exemple de configuration supportant racoon et pluto:
\vspace{5mm} \\
 
 
\hspace{1mm} Ajouter un label/contexte au SPD pour la boucle locale:
 
{\ttfamily
flush;\\ spdflush;\\ spdadd 127.0.0.1 127.0.0.1 tcp -ctx 1 1 "unconfined.user:msg\_filter.role:msg\_filter.ext\_gateway.process:s0" -P out ipsec esp/transport//require;\\ spdadd 127.0.0.1 127.0.0.1 tcp -ctx 1 1 "unconfined.user:msg\_filter.role:msg\_filter.ext\_gateway.process:s0" -P in ipsec esp/transport//require;\\ spdadd 127.0.0.1 127.0.0.1 tcp -ctx 1 1 "unconfined.user:msg\_filter.role:msg\_filter.int\_gateway.process:s0" -P out ipsec esp/transport//require;\\ spdadd 127.0.0.1 127.0.0.1 tcp -ctx 1 1 "unconfined.user:msg\_filter.role:msg\_filter.int\_gateway.process:s0" -P in ipsec esp/transport//require;\\
}
\vspace{8mm}
 
\hspace{1mm} Configuration racoon:
 
{\ttfamily
path include "/etc/racoon";\\ path pre\_shared\_key "/etc/racoon/psk.txt";\\ path certificate "/etc/racoon/certs";\\ path script "/etc/racoon/scripts";\\ \hspace{2mm}\\ sainfo anonymous\\ \{\\ \hspace{2mm}lifetime time 1 hour ;\\ \hspace{2mm}encryption\_algorithm 3des, blowfish 448, rijndael ;\\ \hspace{2mm}authentication\_algorithm hmac\_sha1, hmac\_md5 ;\\ \hspace{2mm}compression\_algorithm deflate ;\\ \}\\
}
\vspace{8mm}
 
\hspace{1mm} Configuration LibreSwan/pluto:
 
{\ttfamily
version 2.0\\ config setup\\ \hspace{2mm}plutorestartoncrash=false\\ \hspace{2mm}protostack=netkey\\ \hspace{2mm}plutodebug="all"\\ \hspace{2mm}secctx\_attr\_value = 32001\\ conn labeled\_loopback\_test\\ \hspace{2mm}auto=start\\ \hspace{2mm}rekey=no\\ \hspace{2mm}authby=secret\\ \hspace{2mm}type=transport\\ \hspace{2mm}left=127.0.0.1\\ \hspace{2mm}right=127.0.0.1\\ \hspace{2mm}ike=3des-sha1\\ \hspace{2mm}phase2=esp\\ \hspace{2mm}phase2alg=aes-sha1\\ \hspace{2mm}loopback=yes\\ \hspace{2mm}labeled\_ipsec=yes\\ \hspace{2mm}policy\_label=unconfined.user:msg\_filter.role:msg\_filter.ext\_gateway.process:s0\\ \hspace{2mm}leftprotoport=tcp\\ \hspace{2mm}rightprotoport=tcp\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Support des machines virtuelles }
 
\
 
\hspace{1mm}  Le support de SELinux est disponible dans KVM/QEMU et Xen. Actuellement le principal support SELinux pour la virtualisation se fait via libvirt qui est une API de virtualisation open-source utilisée pour charger dynamiquement les VM. Les extensions de sécurité ont été ajoutés dans le projets Svirt et l'implémentation pour QEMU/KVM. Les sections qui suivent donnent une introduction à QEMU/KVM, puis libvirt.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Support QEMU/KVM }
 
\
 
\hspace{1mm}  KVM est un module kernel qui utilise le kernel Linux comme hyperviseur et utilise un QEMU modifié pour supporter l'émulation hardware. Le support SELinux pour les VM est implémenté par le sous-système libvirt qui est utilisé pour gérer les images VM en utilisant un VMM, et comme KVM est basé sur Linux il a le support SELinux par défaut. Il y a également des module de stratégie référence pour supporter l'infrastructure générale.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Support libvirt }
 
\
 
\hspace{1mm}  Le projet Svirt a ajouté des hooks de sécurité dans la librairie libvirt qui est utilisée par le service libvirtd. Le fournisseur de VM peut implémenter des mécanismes de sécurité qui nécessite d'utiliser un pilote libvirt spécifique qui va charger et gérer les images. L'implémentation SELinux supporte 4 méthodes de label des images VM, processus et leur ressources associées supporté dans le module modules/services/virt.* de la stratégie référence. Pour supporter le labeling, libvirt nécessite une stratégie MCS ou MLS vu que le level du contexte de sécurité est utilisé (user:role:type:level).
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Labéliser les images VM }
 
\
 
\hspace{1mm}  Le \textbf{labeling dynamique}, Le mode par défaut, lorsque chaque VM est lancé dans son propre domaine configuré dynamiquement et donc isole les VM entre-elles (chaque fois que la VM est lancée un label MCS différent et unique est généré). Ce mode est implémenté comme suit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{6mm} a)]{Un contexte initial pour le processus est obtenu depuis /etc/selinux/<SELINUXTYPE>/contexts/virtual\_domain\_context (défaut: system\_u:system\_r:svirt\_tcg\_t:s0)}
\item[\hspace{6mm} b)]{UN contexte initial pour le fichier image est obtenu depuis /etc/selinux/<SELINUXTYPE>/contexts/virtual\_image\_context (defaut: system\_u:system\_r:svirt\_image\_t:s0 qui autorise la lecture/écriture des fichiers image)}
\item[\hspace{6mm} c)]{Quand l'image est utilisée pour démarrer la VM, un niveau MCS est généré et ajouté au contexte du processus et au contexte du fichier image. Le processus et les fichiers images sont transités dans le contexte via setfilecon et setexeccon.}
\end{description}
 
\hspace{1mm}  Si l'image disque doit être partagé, le niveau dynamiquement alloué sera généré par chaque instance du processus VM, cependant il y aure une seule instance de l'image disque (\textbf{image partagée}).
\vspace{5mm} \\
 
 
\hspace{1mm} La ressource XML pour le contenu de <disk> doit inclure <shareable/>. Avec la stratégie targeted de F-20, l'option shareable donne une erreur, il est donc nécessaire d'activer la mémoire partagée: \\
\hspace{1mm} \textbf{setsebool -P virt\_use\_execmem on} \\
 
\hspace{1mm}  Maintenant que l'image a été configurée comme partageable, le processus d'initialisation commence:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{6mm} a)]{Un contexte initiale pour le processus est obtenu depuis /etc/selinux/<SELINUXTYPE>/contexts/virtual\_domain\_context (défaut: system\_u:system\_r:svirt\_tcg\_t:s0)}
\item[\hspace{6mm} b)]{Un contexte initial pour le lable du fichier image est obtenu depuis /etc/selinux/<SELINUXTYPE>/contexts/virtual\_image\_context. Défaut: system\_r:system\_r:svirt\_image\_t:s0)}
\item[\hspace{6mm} c)]{Quand l'image est utilisée pour démarrer la VM un niveau MCS aléatoire est généré et ajouté au contexte du processus (mais pas le fichier image). Le processus est transité au contexte approprié par les appels setfilecon et setexeccon.}
\end{description}
 
\hspace{1mm}  Il est possible de définir les \textbf{labels statiques}, cependant en conséquence l'image ne peut pas être clonée en utilisant le VMM. C'est la méthoide utilisée pour configurer les VM dans les systèmes MLS via qu'il y a un label connu qui définis le niveau de sécurité. Avec cette méthode il est également possible de configurer 2 ou plusieurs VM avec le même contexte de sécurité pour qu'elles puissent partager des ressources.
\vspace{5mm} \\
 
 
\hspace{1mm} Dans la ressource XML, ajouter:
 
{\ttfamily
...\\ </devices>\\ <seclabel type='static' model='selinux' relabel='no'>\\ \hspace{2mm}<label>system\_u:system\_r:avirt\_t:s0:c1022,c1023</label>\\ </seclabel>\\ \hspace{2mm}\\ \hspace{2mm}</domain>\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Services Sandbox }
 
\
 
\hspace{1mm}  Fedora supporte les 3 type de service sandbox:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{sandboxing non-GUI.}
\item[\hspace{1mm} 2.]{Sandboxing GUI utilisant le serveur Xephyr. Il permet l'isolation d'application X via des serveurs Xephyr imbriqués.}
\end{description}
 
\hspace{1mm}  Ces services sandbox sont définis dans sandbox(3) et sont disponibles dans le package policycoreutils. Ils utilisent seunshare(8), qui permet de lancer des commandes dans un home alternatif. sandbox.conf permet de configurer le nom, cpu et utilisation mémoire.
\vspace{5mm} \\
 
 
\hspace{1mm}  Noter que les services sandbox nécessitent le support MCS vu que les catégories sont utilisées pour isoler les multiples sandbox.
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 3.]{sandboxing pour la virtualisation des application en utilisant soit QEMU/KVM ou LXC. ce service est disponible dans le package libvirt-sandbox et fournis une API et des services en ligne de commande pour démarrer des sessions.}
\end{description}
 
\hspace{1mm}  Le package est construit sur Svirt qui fournis la virtualisation avec SELinux et QEMU/KVM ou LXC pour fournir un environnement de virtualisation. Si le support de KVM n'est pas disponible dans la machine, LXC est l'alternative à utiliser.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Support X-Windows }
 
\
 
\hspace{1mm}  L'implémentation XSELinux fournis un contrôle d'accès fin à la majorité des objets X-server en utilisant une extension X-Windows ajissant comme gestionnaire d'objet. Le nom de l'extension est 'SELinux'.
\vspace{5mm} \\
 
 
\hspace{1mm}  Dans Fedora XSELinux est désactivé dans la stratégie ciblée, mais activée dans la stratégie MLS, dû au fait que Red-Hat préfère utiliser le sandboxing avec Xephyr pour isoler les fenêtres.
\vspace{5mm} \\
 
 
\hspace{1mm}  Il est important de noter que l'OM X-Windows opère sur les objets bas niveau du serveur X. Un gestionnaire comme Gnome ou twm s'appuie dessus, cependant ils ne connaissent pas la stratégie forcée par SELinux.
\vspace{5mm} \\
 
 
{\includegraphics[]{../images/selinux11.png}}
 
\hspace{1mm}  Les composant majeur qui forment XSELinux sont:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} la stratégie]{La stratégie référence a été mise à jours, cependant dans Fedora l'OM est activé pour mls uniquement. (xserver-object-manager).}
\item[\hspace{1mm} libselinux]{La libairie fournie les interfaces nécessaire entre l'OM les services userspaces SELinux, et les services kernel.}
\item[\hspace{1mm} fichier x\_contexts]{Contient les informations de configuration de contexte par défaut qui sont requis par l'OM pour labéliser certains objets. L'OM le lit via selabel\_lookup(3)}
\item[\hspace{1mm} XSELinux Object Manager]{C'est une extension pour X-server qui agit comme médiateur pour les décisions d'accès entre X-server (via XACE) et le serveur de sécurité SELinux. l'OM est initialisé avant que les X-clients se connectent au X-server.}
\item[\hspace{1mm} XACE]{X Access Control Extension peut être utilisé par d'autres extensions de sécurité de contrôle d'accès, pas seulement SELinux.}
\item[\hspace{1mm} X-server]{Le cœur du serveur X-Windows qui gère les requêtes et réponses depuis/vers les clients X en utilisant le protocole X. l'OM XSELinux intercepte ces requêtes/réponses via XACE et force les décisions de la stratégie}
\item[\hspace{1mm} X-clients]{Ils se connectent au serveur X et sont généralement des gestionnaires de fenêtre comme Gnome ou KDE.}
\end{description}
 
\vspace{1cm}{\huge Polyinstanciation }
 
\
 
\hspace{1mm}  Les services OM/XACE supportent la polyinstanciation des propriétés et séléctions permettant d'être groupés dans différentes zones d'appartenance pour qu'un groupe ne connaisse pas l'existance des autres. Pour implémenter la polyinstanciation, le mot clé poly\_ est utilisé dans le fichier x\_context pour les séléctions et propriétés requises. Il devrait y avoir une règle type\_member dans la stratégie pour forcer la séparation en calculant un nouveau context avec soit security\_compute\_member ou avc\_compute\_member
\vspace{5mm} \\
 
 
\hspace{1mm}  Noter que la stratégie référence actuelle n'implémente pas la polyinstanciation, mais la stratégie MLS utilise les règles mlsconstrain pour limiter le périmètre des propriétés et sélections.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Information de configuration }
 
\
 
\hspace{1mm}  La stratégie référence a un booléen xserver\_object\_manager qui active/désactive le module de stratégie X-Server.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le gestionnaire d'objet est traité comme une extension X-server et son opcode majeur peut être requêté avec la fonction Xlib XQueryExtension.
\vspace{5mm} \\
 
 
\hspace{1mm} Si l'OM X-server doit tourner dans un mode SELinux spécifique, l'option peut être ajoutée dans le fichier xorg.conf (SELInux mode disabled|permissive|enforcing). S'il n'y a pas d'entrée, l'OM suit le mode courant
 
{\ttfamily
Section "Module"\\ \hspace{2mm}SubSection "extmod"\\ \hspace{2mm}\hspace{2mm}Option "SELinux mode enforcing"\\ \hspace{2mm}EndSubSection\\ EndSection\\
}
\vspace{8mm}
 
\hspace{1mm}  Le fichier x\_contexts contient les informations de contexte par défaut requis par l'OM pour initialiser le service et labéliser les objets quand ils sont créés. La stratégie nécessite également de connaître ces informaions de contexte pour forcer la stratégie ou la transition des nouveaux objets. Une entrée typique est comme suit:
\vspace{5mm} \\
 
 
\hspace{1mm} \# object\_type object\_name context \\
\hspace{1mm} \textbf{selection PRIMARY system\_u:object\_r:clipboard\_xselection\_t:s0} \\
\hspace{1mm} ou pour la polyinstanciation \\
\hspace{1mm} \textbf{poly\_selection PRIMARY system\_u:object\_r:clipboard\_xselection\_t:s0} \\
 
\hspace{1mm}  object\_name peut contenir '*' pour any ou '?' pour substitue. les entrées object\_type sont client, property, poly\_property, extension, selection, poly\_selection et events.
\vspace{5mm} \\
 
 
\hspace{1mm}  Les entrées object\_name peuvent être tout nom de ressource X qui sont définis dans le code source du serveur X et peuvent être trouvé dans protocol.txt et le fichier source BuildInAtoms.
\vspace{5mm} \\
\hspace{1mm}  \textbf{Notes:}
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1)]{La manière dont le code XSELinux foncion est que les entrées non-poly sont recherchés en premier, si une entrée n'est pas trouvée, cherche une entrée poly. La raison de ce comportement est qu'en opérant dans un environnement sécurisé tous les objets sont polyinstanciés sauf s'il y des exception pour certains objets.}
\item[\hspace{1mm} 2)]{Pour les systèmes utilisant la stratégie référence tous les clients X se connectant à distance reçoivent un contexte de sécurité depuis le fichier x\_contexts.}
\end{description}
 
\vspace{1cm}{\huge SE-PostgreSQL }
 
\
 
\hspace{1mm}  L'extension sepgsql permet de labéliser les objets de base PostgreSQL. Le labéling au niveau des entrées n'est plus supporté.
\vspace{5mm} \\
 
 
\hspace{1mm}  l'extension segpsql ajoute SELinux aux objets de base de données tels que les tables, colonnes, views, fonctions, schemas et séquences.
\vspace{5mm} \\
 
 
{\includegraphics[]{../images/selinux12.png}}
 
\hspace{1mm}  Pour utiliser SE-PostgreSQL chaque utilisateur GNU/Linux doit avoir un rôle de base de données valide (à ne pas confondre avec un rôle SELinx). L'installation par défaut ajoute automatiquement un utilisateur pgsql avec un rôle de base de données adapté.
\vspace{5mm} \\
 
 
\hspace{1mm}  Si un client se connecte à distance et qu'un label réseau est requis, il est possible d'utiliser IPSec ou NetLabel. Dans l'illustration ci-dessous, l'application cliente se connecte à une base et exécute les commandes SQL. vu que les commandes SQL sont traités par PostgreSQL, chaque opération effectuées sur un objet est vérifié par l'OM pour voir si l'opération est permise
\vspace{5mm} \\
 
 
{\includegraphics[]{../images/selinux13.png}}
 
\hspace{1mm} La commande sql SECURITY LABEL a été ajoutée à PostgreSQL pour autoriser les fournisseurs de sécurité à labéliser ou changer un label dans les objets de base de données. Le format de la commande est:
 
{\ttfamily
SECURITY LABEL \texttt{[} FOR provider \texttt{]} ON\\ \{\\ \hspace{2mm}TABLE object\_name |\\ \hspace{2mm}COLUMN table\_name.column\_name |\\ \hspace{2mm}AGGREGATE agg\_name (agg\_type \texttt{[}, ...\texttt{]} ) |\\ \hspace{2mm}DATABASE object\_name |\\ \hspace{2mm}DOMAIN object\_name |\\ \hspace{2mm}EVENT TRIGGER object\_name |\\ \hspace{2mm}FOREIGN TABLE object\_name\\ \hspace{2mm}FUNCTION function\_name ( \texttt{[} \texttt{[} argmode \texttt{]} \texttt{[} argname \texttt{]} argtype\\ \texttt{[}, ...\texttt{]} \texttt{]} ) |\\ \hspace{2mm}LARGE OBJECT large\_object\_oid |\\ \hspace{2mm}\texttt{[} PROCEDURAL \texttt{]} LANGUAGE object\_name |\\ \hspace{2mm}ROLE object\_name |\\ \hspace{2mm}SCHEMA object\_name |\\ \hspace{2mm}SEQUENCE object\_name |\\ \hspace{2mm}TABLESPACE object\_name |\\ \hspace{2mm}TYPE object\_name |\\ \hspace{2mm}VIEW object\_name\\ \} IS 'label'\\
}
\vspace{8mm}
 
\hspace{1mm} Quelques exemples: \\
\hspace{1mm} \textbf{SECURITY LABEL ON SCHEMA test\_ns IS 'unconfined\_u:object\_r:sepgsql\_schema\_t:s0:c10';} \\
\hspace{1mm} \textbf{SECURITY LABEL ON TABLE test\_ns.info IS 'unconfined\_u:object\_r:sepgsql\_table\_t:s0:c20';} \\
\hspace{1mm} \textbf{SECURITY LABEL ON COLUMN test\_ns.info.user\_name IS 'unconfined\_u:object\_r:sepgsql\_table\_t:s0:c30';} \\
\hspace{1mm} \textbf{SECURITY LABEL ON COLUMN test\_ns.info.email\_addr IS 'unconfined\_u:object\_r:sepgsql\_table\_t:s0:c40';} \\
 
\vspace{1cm}{\huge Fonctions SQL additionnelles }
 
\
 
\hspace{1mm}  les fonctions suivantes ont été ajoutées:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} sepgsql\_getcon]{Retourne le contexte de sécurité du client}
\item[\hspace{1mm} sepgsql\_mcstrans\_in(text con)]{Traduit la plage du contexte en format brut fournis par mcstransd}
\item[\hspace{1mm} sepgsql\_restorecon(text specfile)]{Définis les contextes de sécurité dans tous les objets de base de données en accord avec specfile. Normalement utilisé à l'initialisation}
\end{description}
 
\vspace{1cm}{\huge postgresql.conf }
 
\
 
\hspace{1mm}  Le fichier postgresql.conf supporte les entrées additionnelles suivante pour permettre et gérer SE-PostgreSQL:
\vspace{5mm} \\
 
 
\hspace{1mm} Cette entrée est obligatoire pour active l'extension sepgsql \\
\hspace{1mm} \textbf{shared\_preload\_libraries = 'sepgsql'} \\
\hspace{1mm} Permet de personnaliser les entrées sepgsql \\
\hspace{1mm} \textbf{custom\_variable\_classes = 'sepgsql'} \\
\hspace{1mm} Permet de lancer sepgsql en mode permissive \\
\hspace{1mm} \textbf{sepgsql.permissive = on} \\
\hspace{1mm} ACtive les messages d'audit sans regarder les paramètres de la stratégie \\
\hspace{1mm} \textbf{sepgsql.debug\_audit = on} \\
 
\hspace{1mm} pour voir ces paramètres, la déclaration SHOW peut être utilisée: \\
\hspace{1mm} \textbf{SHOW sepgsql.permissive;} \\
\hspace{1mm} \textbf{SHOW sepgsql.debug\_audit;} \\
 
\hspace{1mm}  SE-PostgreSQL gère ses propres entrées d'audit AVC dans les logs standard PostgreSQL dans /var/lib/pgsql/data/pg\_log, et par défaut seul les erreurs sont loggés. 'sepgsql.debug\_audit = on' peut être spécifié pour logger tous les évènements d'audit.
\vspace{5mm} \\
 
 
\hspace{1mm}  Pour supporter les opérations de base de données PostgreSQL a des tables internes dans le catalogue système qui maintient les informations sur les bases, tables, etc. Cette section discute de la table pg\_seclabel qui maintient les labels de sécurité et autres références.
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} objoid]{L'OID de l'objet pour lequel ce label est pertinent}
\item[\hspace{1mm} classoid]{L'OID du catalogue système dans lequel cet objet apparaît}
\item[\hspace{1mm} objsubid]{Pour un label de sécurité dans une colonne, c'est le numéro de colonne. Pour tous les autres objets cette colonne est 0.}
\item[\hspace{1mm} provider]{Fournisseur de label associé avec ce label. Actuellement seul SELinux est supporté}
\item[\hspace{1mm} lael]{Label de sécurité appliqué à cet objet}
\end{description}
 
\hspace{1mm} Ce sont des entrées prises depuis un 'SELECT * FROM pg\_seclabel;' d'une base de test:
 
{\ttfamily
objoid | classoid | objsubid | provider | label\\ -------+----------+----------+----------+----------------------------------------------\\ 16390 | 2615 | 0 | selinux | unconfined\_u:object\_r:sepgsql\_schema\_t:s0:c10\\ 16391 | 1259 | 0 | selinux | unconfined\_u:object\_r:sepgsql\_table\_t:s0:c20\\ 16391 | 1259 | 1 | selinux | unconfined\_u:object\_r:sepgsql\_table\_t:s0:c30\\ 16391 | 1259 | 2 | selinux | unconfined\_u:object\_r:sepgsql\_table\_t:s0:c40\\
}
\vspace{8mm}
 
\hspace{1mm} La première entrée est le schéma, le second la table elle-même, et les 2 dernières sont les colonnes 1 et 2. Il y a également une vue intégrée pour afficher des détails sur les labels de sécurité appelés pg\_seclabels. 'SELECT * FROM pg\_seclabels;' pour l'afficher:
 
{\ttfamily
objoid | classoid | objsubid | objtype | objnamespace | objname | provider | label\\ -------+----------+----------+---------+--------------+---------+----------+----------------------------\\ 16390 | 2615 | 0 | schema | 16390 | test\_ns | selinux | unconfined\_u:object\_r:sepgsql\_schema\_t:s0:c10\\ 16391 | 1259 | 0 | table | 16390 | test\_ns.info | selinux | unconfined\_u:object\_r:sepgsql\_table\_t:s0:c20\\ 16391 | 1259 | 1 | column | 16390 | test\_ns.info.user\_name | selinux | unconfined\_u:object\_r:sepgsql\_table\_t:s0:c30\\ 16391 | 1259 | 2 | column | 16390 | test\_ns.info.email\_addr| selinux | unconfined\_u:object\_r:sepgsql\_table\_t:s0:c40\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Support Apache }
 
\
 
\hspace{1mm}  Les serveurs Apache sont supportés par SELinux en utilisant les modules de stratégie Apache de la stratégie référence (les modules httpd), cependant il n'y a pas de gestionnaire d'objet Apache. Il y a une librairie partagée qui permet un contrôle d'accès fin en utilisant Apache avec les threads. Le module additionel est appelé mod\_selinux.so et supporte le module de stratégie appelé mod\_selinux.pp
\vspace{5mm} \\
 
 
\hspace{1mm}  mod\_selinux utiliser la déclaration typebounds qui a été introduit dans la version 24 de la stratégie. Il permets les threads dans une application multi-thread comme apache d'être lié dans un jeu de permissions définis et le domaine enfant ne peut pas avoir plus de permissions que le domaine parent.
\vspace{5mm} \\
 
 
\hspace{1mm}  Ces composants sont connus sous le nom Apache/SELinux Plus. L'objectif de ces services addon Apache est de créer une pile web compatible SELinux. Par exemple, la pile LAPP (Linux, Apache, PostgreSQL, PHP/Perl/Python) a le support suivant:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} L]{Linux support SELinux}
\item[\hspace{1mm} A]{Apache a un support partiel de SELinux}
\item[\hspace{1mm} P]{PostgreSQL supporte SELinux avec SE-PostgreSQL}
\item[\hspace{1mm} P]{PHP/Perl/Python ne sont pas actuellement compatible SELinux, cependant PHP et Python ont un support pour les fonctions de la libselinux: php-pecl-selinux et libselinux-python.}
\end{description}
 
\vspace{1cm}{\huge mod\_selinux }
 
\
 
\hspace{1mm}  Ce module autorise une application web d'être lancé par Apache avec un contexte de sécurité basé sur la stratégie au lieu que le serveur web le traite lui-même. par exemple:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} 1.]{Un utitisateur envoie une requête HTTP à Apache qui nécessite les services d'une application web}
\item[\hspace{1mm} 2.]{Apache reçois la requête et lance l'instance de l'application web pour effectuer la tâche:}
\end{description}
 
\begin{description} \normalsize
\item[\hspace{6mm} a)]{Sans mod\_seliunx activé le contexte de sécurité des applications web sont identique au processus apache, il n'y a pas de restriction de privilèges}
\item[\hspace{6mm} b)]{Avec mod\_selinux activé, l'application web est lancée avec le contexte de sécurité définis dans mod\_selinux.conf}
\end{description}
 
\hspace{1mm}  L'application web quitte, redonnant le contrôle au serveur web qui répond avec la réponse HTTP.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Limites }
 
\
 
\hspace{1mm} Parce que plusieurs threads partagent le même segment mémoire, SELinux ne peut pas vérifier les flux d'informations entre ces différents threads en utilisant setcon(3) avant le kernel 2.6.28. Pour résoudre ce problème la déclaration typebounds a été introduite qui stoppe un thread enfant ayant des privilèges supérieur au thread parent. par exemple la déclaration typebounds et les règles allow:
 
{\ttfamily
typebounds httpd\_t httpd\_child\_t;\\ allow httpd\_t etc\_t : file \{ getattr read \};\\ allow httpd\_child\_t etc\_t : file \{ read write \};\\
}
\vspace{8mm}
 
\hspace{1mm}  Déclare que le domaine parent (httpd\_t) a les permissions file : \{ getattr read \}. Cependant le domaine enfant (httpd\_child\_t) a les permission file : \{ read write \}. Cela ne sera pas permis par le kernel parce que le parent n'a pas les permissions write, et s'assure que le domaine enfant aura toujours les même permissions ou moins de permissions que le parent.
\vspace{5mm} \\
 
 
\hspace{1mm}  Quand setcon(3) est utilisé pour définir un contexte différent dans un nouveau thread sans une déclaration typebounds associée, l'appel retourne 'Operation not permitted' et une entrée SELINUX\_ERR est ajoutée au logs d'autid indiquant 'op=security\_bounded\_transition result\_denied' avec les ancien et nouveau contexte.
\vspace{5mm} \\
 
 
\hspace{1mm}  S'il y a une déclaration typebounds valide et que le domaine enfant tente d'obtenir un privilège supérieur que le domaine parent est refusé avec une entrée SELINUX\_ERR ajoutée dans les log d'audit indiquant 'op=security\_compute\_av reason=bounds'.
\vspace{5mm} \\
 
 
\hspace{1mm}  Le document d'exemple contient 2 démonstrations utilisant setcon(3) avec les threads et comment la déclaration typebounds est utilisée pour autoriser un thread à être exécuté. Il sont localisés dans libselinux/examples et sont:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} a)]{setcon\_thread1\_example.c - qui appelle setcon dans le processus principal et lance un thread. Si le module setcon\_example.conf est chargé et qu'une contexte "unconfined\_u:unconfined\_r:user\_t:s0" est sélectionné, un message d'erreur est affiché: "setcon\_raw - ERROR: Operation not permitted"}
\item[\hspace{1mm} b)]{setcon\_thread2\_example.c - ces fonctions sont similaire, cependant il appel setcon depuis un thread}
\end{description}
 
\vspace{1cm}{\huge Fichiers de configuration de SELinux }
 
\
 
\hspace{1mm}  Cette section explique chaque fichier de configuration SELinux. Les fichiers de configuration sont classés comme suit:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} configuration globale]{- affecte la stratégie active et les application supportant SELinux, utilitaires et commandes}
\item[\hspace{1mm} configuration de stratégie]{- utilisés par une stratégie active}
\item[\hspace{1mm} configuration kernel]{- localisé sous /sys/fs/selinux et reflète la configuration courante}
\end{description}
 
\vspace{1cm}{\huge Migration du magasin de stratégie }
 
\
 
\hspace{1mm}  Quand les distributions sont passés à la version 2.4 de libsemanage, libsepol et policycoreutils, le magasin de module de stratégie a été déplacé vers /var/lib/selinux/<SELINUXTYPE>. Une fois les librairies mis à jours, tous les magasins doivent être migrés avant que toute commande soit exécutée. Une fois la migration complétée, il est possible de construire les stratégies contenant un mix des modules de stratégie référence, modules de langage de stratégie kernel et modules écris en CIL comme dans l'exemple suivant:
\vspace{5mm} \\
 
 
\hspace{1mm} Compiler et installer une base et 2 modules écrits en langage kernel \\
\hspace{1mm} \textbf{checkmodule -o base.mod base.conf} \\
\hspace{1mm} \textbf{semodule\_package -o base.pp base.mod -f base.fc} \\
\hspace{1mm} \textbf{checkmodule -m ext\_gateway.conf -o ext\_gateway.mod} \\
\hspace{1mm} \textbf{semodule\_package -o ext\_gateway.pp -m ext\_gateway.mod -f gateway.fc} \\
\hspace{1mm} \textbf{checkmodule -m int\_gateway.conf -o int\_gateway.mod} \\
\hspace{1mm} \textbf{semodule\_package -o int\_gateway.pp -m int\_gateway.mod} \\
\hspace{1mm} \textbf{semodule -s modular-test --priority 100 -i base.pp ext\_gateway.pp int\_gateway.pp} \\
\hspace{1mm} Compiler et installer un module écrit en CIL \\
\hspace{1mm} \textbf{semodule -s modular-test --priority 400 -i custom/int\_gateway.cli} \\
\hspace{1mm} Affiche la liste des modules: \\
\hspace{1mm} \textbf{semodule -s modular-test --list-modules=full} \\
\hspace{1mm} affiche un listing standard des modules \\
\hspace{1mm} \textbf{semodule -s modular-test --list-modules=standard} \\
 
\hspace{1mm}  Noter l'utilisation de --priority disponible après migration de semodule. Les priorités permettent d'avoir plusieurs modules avec le même nom dans le magasin de stratégie. Le module ayant la priorité la plus haute est incluse dans le binaire kernel final, les autres sont ignorés.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge /etc/selinux/config }
 
\
 
\hspace{1mm}  Ce fichier est obligatoire, sans lui, ou corrompu, aucune stratégie SELinux n'est chargée et SELinux est désactivé.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge /etc/selinux/semanage.conf }
 
\
 
\hspace{1mm}  Ce fichier contrôle la configuration et les actions de semanage et semodule.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge /etc/selinux/restorecond[-user].conf }
 
\
 
\hspace{1mm}  Ces fichiers contient les fichiers et répertoire que restorecond surveille afin de corriger le contexte de sécurité
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge /etc/selinux/newrole\_pam.conf }
 
\
 
\hspace{1mm}  Ce fichier est utilisé par la commande newrole et mappe les applications ou commandes en fichiers de configuration PAM. Chaque ligne contient le nom du fichier exécutable suivi par le nom d'un fichier de configuration pam qui existe dans /etc/pam.d
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge /etc/sestatus.conf }
 
\
 
\hspace{1mm}  Utilisé par sestatus pour lister les fichiers et processus dont le contexte de sécurité doit être affiché avec -v.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge /etc/security/sepermit.conf }
 
\
 
\hspace{1mm}  Fichier de configuration pour le module PAM pam\_sepermit
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Fichiers de configuration du magasin de stratégie }
 
\
 
\hspace{1mm}  /var/lib/selinux/<policy\_name>/modules. Noter qu'il peut y avoir plusieurs magasins de stratégie dans un système, chaque fichier décris dans cette section est relatif à ./<policy\_name>. Ces fichiers sont installés, mis à jours ou construit par semodule et semanage. Les fichiers résultant sont soit copiés dans le répertoire, ou utilisés pour reconstruire la stratégie binaire kernel dans /etc/selinux/<policy\_name>/policy.
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} modules/]{le magasin a 2 fichiers de lock utilisés par libsemanage pour gérer les magasin (semanage.read.LOCK et semanage.trans.LOCK)}
\item[\hspace{1mm} modules/active/base.pp]{Package de stratégie de base qui contient les modules obligatoires et les composants de stratégie tels que les classe objets, déclarations de permission et SID initiaux.}
\item[\hspace{1mm} modules/active/base.linked]{Seulement présent si save-linked vaut TRUE dans semanage.conf. Il contient les modules qui ont été liés avec semodule\_link}
\item[\hspace{1mm} modules/active/commit\_num]{Fichier binaire utilisé par libsemanage pour gérer les mises à jours dans le magasin.}
\item[\hspace{1mm} modules/active/file\_contexts.template]{Contient une copie de toutes les entrées de module 'Labeling Policy File' qui ont été extraits de base.pp et les modules chargeables dans le répertoire modules/active/modules. Ces entrées sont utilisées pour construire les fichiers suivants:}
\end{description}
 
\begin{description} \normalsize
\item[\hspace{6mm} homedir\_template]{Utilisé pour produire le fichier file\_contexts.homedirs qui devient ensuite le fichier contexts/files/file\_contexts.homedirs}
\item[\hspace{6mm} file\_contexts]{Qui devient ensuite le fichier contexts/files/file\_contexts}
\end{description}
 
\hspace{1mm}  Noter que dans le processus de construction de semanage, ces 2 fichiers on également les fichiers file\_contexts.bin et file\_contexts.homedirs.bin présents dans contexts/files, dû au fait que semanage nécessite des expression régulière Perl (PCRE). Ils sont générés par sefcontext\_compile.
\vspace{5mm} \\
 
 
\hspace{1mm}  homedir\_template
\vspace{5mm} \\
\hspace{1mm}  file\_contexts
\vspace{5mm} \\
 
 
\hspace{1mm} Le format du fichier file\_contexts.template est comme suit:
 
{\ttfamily
pathname\_regexp \texttt{[}file\_type\texttt{]} opt\_security\_context\\
}
\vspace{8mm}
 
\begin{description} \normalsize
\item[\hspace{1mm} pathname\_regexp]{Une entrée qui définis le chemin qui peut être une expression régulière}
\item[\hspace{1mm} file\_type]{Une des entrées optionnelles suivante: -b|c|d|p|l|s|-.}
\item[\hspace{1mm} opt\_security\_context]{Cette entrée peut être soit le contexte de sécurité, incluant le niveau et plage MLS/MCS, ou la valeur <<none>> pour indiquer que les fichiers qui matchent ne devraient pas être relabélisés}
\end{description}
 
\hspace{1mm}  Les mots clé qui peuvent être dans ce fichier sont:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} HOME\_ROOT]{Remplacé par le répertoire racine des répertoires personnels, normalement /home.}
\item[\hspace{1mm} HOME\_DIR]{Répertoire des répertoires personnels utilisateurs, défaut /home.}
\item[\hspace{1mm} USER]{Remplacé par le user id}
\item[\hspace{1mm} ROLE]{Remplacé par l'entrée 'prefix' du fichier de configuration users\_extra qui correspond au user id des utilisateurs SELinux.}
\end{description}
 
\vspace{1cm}{\huge Exemple de file\_contexts.template }
 
\
 
{\ttfamily
/. /.. /.config /.hcwd /.local system\_u:object\_r:default\_t:s0\\ /\texttt{[}\textasciicircum /\texttt{]}+ -- system\_u:object\_r:etc\_runtime\_t:s0\\ /a?quota\textbackslash{}.(user|group) -- system\_u:object\_r:quota\_db\_t:s0\\ /nsr(/.*)? system\_u:object\_r:var\_t:s0\\ /sys(/.*)? system\_u:object\_r:sysfs\_t:s0\\ ...\\ /etc/ntop.* system\_u:object\_r:ntop\_etc\_t:s0\\ HOME\_DIR/.+ system\_u:object\_r:user\_home\_t:s0\\ /dev/dri/.+ -c system\_u:object\_r:dri\_device\_t:s0\\ ...\\ /tmp/gconfd-USER -d system\_u:object\_r:user\_tmp\_t:s0\\ ...\\ /tmp/gconfd-USER/.* -- system\_u:object\_r:gconf\_tmp\_t:s0\\ ...\\ HOME\_ROOT/\textbackslash{}.journal <<none>>\\
}
\vspace{8mm}
 
\begin{description} \normalsize
\item[\hspace{1mm} modules/active/file\_contexts]{Ce fichier devient les fichiers de stratégie contexts/files/file\_contexts et est construit depui modules/active/file\_contexts.template. Il est ensuite utilisé par les utilitaires de labéling de fichier pour s'assurer que les fichiers et répertoires sont labélisés en accord avec la stratégie.}
\item[\hspace{1mm} modules/active/homedir\_template]{Ce fichier est construit depuis les entrées dans le fichier file\_contexts.template et utilisé par genhomedircon,semanage login, et semanage user pour générer des entrées utilisateurs dans le fichier file\_contexts.homedirs}
\item[\hspace{1mm} modules/active/file\_contexts.homedirs]{Ce fichier devient le fichier de stratégie contexts/files/file\_contexts.homedirs en construisant la stratégie. Il est ensuite utilisé par les utilitaires de label de fichier pour s'assurer que les répertoires home sont labélisés en accord avec la stratégie.}
\item[\hspace{1mm} modules/active/netfilter\_contexts \& netfilter.local]{Ces fichiers ne sont pas utilisés pour le moment. Contiennent du code pour produire un fichier netfilter\_contexts à utiliser par le services iptables.}
\item[\hspace{1mm} modules/active/policy.kern]{Ce fichier binaire construite pas semanage ou semodule, qui devient la stratégie binaire policy/policy.[ver] qui sera chargé dans le kernel}
\item[\hspace{1mm} modules/active/seusers.final \& seusers]{Le fichier seusers.final mappe les utilisateurs GNU/Linux en utilisateurs SELinux et devient le fichier seusers. seusers.final est construit ou modifié en construisant une stratégie ou un fichier optionnel seusers est inclus dans le package de base ou par la commande semanage login.}
\item[\hspace{1mm} modules/active/users\_extra, users\_extra.local, users.local]{users\_extra et users\_extra.local sont utilisés pour mapper un préfixe en répertoires personnels utilisateurs, où il est utilisé pour remplacer le mot clé ROLE. Le préfixe est lié à un utilisateur SELinux et devrait refléter le rôle de l'utilisateur. La commande semanage user permet d'ajouter un préfixe. users\_extra contient toutes les entrées de préfixe de stratégie, et users\_extra.local contient ceux générés par semanage user. users.local est utilisé pour ajouter de nouveaux utilisateurs SELinux à la stratégie sans éditer la stratégie.}
\item[\hspace{1mm} modules/active/booleans.local]{Ce fichier est créé et mis à jours par semanage boolean et maintient les booléens}
\item[\hspace{1mm} modules/active/file\_contexts.local]{Ce fichier est créé et mis à jours par semanage fcontext et maintient les informations de contexte de fichiers et répertoires qui ne sont pas fournis par la stratégie core (ex: ne sont pas définis dans des fichiers .fc)}
\item[\hspace{1mm} modules/active/interfaces.local]{Ce fichier est créé et mis à jours par la commande semanage interface et maintient les informations d'interface réseaux qui ne sont pas fournies par la stratégie core (ex: ne sont pas définis dans le fichier base.conf). Les nouvelles informations sont ensuite construites dans la stratégie par la commande semanage. Chaque ligne contient une déclaration netifcon.}
\item[\hspace{1mm} modules/active/nodes.local]{Ce fichier est créé ni mis à jours par la commande semanage node et maintient des informations sur les adresses réseaux qui ne sont pas fournies par la stratégie core (ne sont pas définis dans base.conf). Ces informations sont ensuite construite dans la stratégie par la commande semanage. Chaque ligne contient une déclaration nodecon.}
\item[\hspace{1mm} modules/active/ports.local]{Ce fichier est créé et mis à jours par semanage port et maintient les informations sur les port réseaux qui n'ont pas été fournis par la stratégie core. Chaque ligne contient une déclaration portcon}
\item[\hspace{1mm} modules/active/preserve\_tunables]{Ce fichier n'existe que si la stratégie construite préserve les personnalisations.}
\item[\hspace{1mm} modules/active/disable\_dontaudit]{Ce fichier n'existe que si la stratégie construite en ayant désactivé les règles dontaudit}
\item[\hspace{1mm} modules/active/modules]{Ce répertoire contient des modules chargeable (<module\_name>.pp ou <module\_name>.pp.disabled si désactivé) qui ont été construits par la commande semodule\_package et placées dans le magasin par les commande semodule ou semanage module -a.}
\end{description}
 
\vspace{1cm}{\huge Fichiers de configuration de stratégie }
 
\
 
\hspace{1mm}  Chaque fichier dans cette section est relatif à /etc/selinux/<policy\_name>. La majorité des fichiers sont installés par la stratégie référence, semanage ou semodule. Il est possible de construire des stratégie monolitiques personnalisée qui utilisent seulement les fichiers installés dans cette zone (ex: n'utilise pas semanage ou semoduleè).
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} policy/policy.29]{Stratégie binaire chargée dans le kernel}
\item[\hspace{1mm} context/files/file\_contexts]{Pour permettre au système de fichier d'être relabelisé}
\item[\hspace{1mm} context/dbus\_contexts]{Pour permettre au service de messagerie dbus à fonctionner sous SELinux}
\item[\hspace{1mm} context/x\_contexts]{Pour autoriser le service X-Windows à fonctionner sous SELinux}
\end{description}
 
\vspace{1cm}{\huge fichier seusers }
 
\
 
\hspace{1mm}  Le fichier seusers est utilisé par les programes login et par les utilisateurs GNU/Linux en utilisateurs SELinux. Une séquence de connexion serait:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} -]{En utiliser le userid GNU/Linux, recherche re selinux\_id dans ce fichier. S'il n'est pas trouvé, utilise l'entrée \_\_default\_\_}
\item[\hspace{1mm} -]{Pour déterminer le contexte à utiliser, lit contexts/users/[seuser\_id]. S'il n'est pas présent:}
\end{description}
 
\begin{description} \normalsize
\item[\hspace{6mm} -]{Recherche un contexte par défaut dans contexts/default\_contexts. Si aucun contexte par défaut n'est trouvé, lit contexts/failsafe\_context pour autoriser un contexte sûr.}
\end{description}
 
\hspace{1mm}  Noter que l'utilisateur system\_u est définis dans ce fichier, cependant il ne doit pas y avoir d'utilisateur GNU/Linux system\_u dans le système.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Fichiers booleans et booleans.local }
 
\
 
\hspace{1mm}  Dépréciés et généralement non présent, ces fichiers gèrent les booléens.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge booleans.subs\_dist }
 
\
 
\hspace{1mm}  Ce fichier, si présent, permet d'allouer de nouveaux noms de booléens dans la stratégie active. Ce fichier a été ajouté parce que beaucoup d'anciennes booléennes commençaient avec 'allow' qui rendait difficile à déterminer ce qu'ils faisaient. Par exemple allow\_console\_login et plus compréhensible avec login\_console\_enabled. Si ce fichier est présent, les 2 noms peuvent être utilisés. Chaque ligne est sous la forme \textbf{policy\_bool\_name new\_name}.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge setrans.conf }
 
\
 
\hspace{1mm}  Ce fichier est utilisé par mcstrands pour traduire les niveaux de stratégies MCS/MLS en labels user friendly.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge secolor.conf }
 
\
 
\hspace{1mm}  secolor.conf contrôle la couleur associée avec les composant d'un contexte quand les informations sont affichées par SELinux par une application gérant les couleurs.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge policy/policy.<ver> }
 
\
 
\hspace{1mm}  Fichier de stratégie binaire qui est chargé dans le kernel pour forcer la stratégie et est construit par checkpolicy ou semodule. Par convention l'extention du nom de fichier est la version de la base de stratégie utilisée pour construire la stratégie.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/customizable\_types }
 
\
 
\hspace{1mm}  Ce fichier contient une liste de types qui ne sont pas relabélisés par setfiles ou restorecon. Les commandes vérifient ce fichier avant de relabéliser et exclus ceux dans cette liste sauf si -F est utilisé.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/default\_contexts }
 
\
 
\hspace{1mm}  Ce fichier est utilisé par les application compatible SELinux pour définir un contexte de sécurité pour les processus utilisateurs (généralement les applications login) où l'identité de l'utilisateur GNU/Linux doit être connu par l'application.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/dbus\_contexts }
 
\
 
\hspace{1mm}  Ce fichier est pour le service de messagerie dbus qui est utilisé par certaines applications comme KDE. Si SELinux est activé, ce fichier doit exister pour que ces applications puissent fonctionner.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/default\_type }
 
\
 
\hspace{1mm}  Le fichier permet aux applications comme newrole de sélectionner un type par défaut pour un rôle si aucun n'est fournis.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/failsafe\_context }
 
\
 
\hspace{1mm}  Le fichier failsafe\_context est utilisé quand un process login ne peut déterminer un contexte par défaut à utiliser. Le contenu du fichier est utilisé pour permettre à un administrateur d'accéder au système.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/initrc\_context }
 
\
 
\hspace{1mm}  Utilisé par la commande run\_init pour permettre de démarrer les services système dans le même contexte de sécurité que init.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/lxc\_contexts }
 
\
 
\hspace{1mm} Ce fichier supporte le labéling des conteneurs lxc dans la librairie libvirt. Le format est le suivant:
 
{\ttfamily
process = "security\_context"\\ file = "security\_context"\\ content = "security\_context"\\
}
\vspace{8mm}
 
\begin{description} \normalsize
\item[\hspace{1mm} process]{Une entrée qui contient le contexte de sécurité de domaine lxc}
\item[\hspace{1mm} file]{contient le contexte de sécurité de fichier lxc}
\item[\hspace{1mm} content]{Une entrée qui contient le contexte de sécurité de contenu lxc}
\item[\hspace{1mm} sandbox\_kvm\_process]{}
\item[\hspace{1mm} sandbox\_lxc\_process]{Ces entrées peuvent être présents}
\end{description}
 
\vspace{1cm}{\huge contexts/netfilter\_contexts }
 
\
 
\hspace{1mm}  Ce fichier supporte le labeling Secmark pour netfilter/iptable. Il n'est pas utilisé actuellement.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/removable\_context }
 
\
 
\hspace{1mm}  Ce fichier contient un label par défaut pour les périphérique hot-plug qui ne sont pas définis dans contexts/files/media.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/securetty\_types }
 
\
 
\hspace{1mm}  Utilisé par newrole pour trouver le type à utiliser avec les périphériques tty en changeant les rôles ou niveaux.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/sepgsql\_contexts }
 
\
 
\hspace{1mm}  Ce fichier contient les contextes de sécurité par défaut pour les objets de base SE-PostgreSQL, décrit dans selabel\_db
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/systemd\_contexts }
 
\
 
\hspace{1mm} Ce fichier contient les contextes de fichiers utilisé par les tâches lancées via systemd. Le format est \textbf{service\_class = security\_context}.Exemple:
 
{\ttfamily
runtime=system\_u:object\_r:systemd\_runtime\_unit\_file\_t:s0\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge contexts/userhelper\_context }
 
\
 
\hspace{1mm}  Ce fichier contient le contexte de sécurité par défaut utilisé par les applications system-config-*, lancés en root.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/virtual\_domain\_context }
 
\
 
\hspace{1mm}  Ce fichier est utilisé par libvirt et fournis les contextes de domaine qemu disponibles dans la stratégie. Il peut y avoir 2 entrées dans ce fichier, la deuxième étant un contexte alternatif.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/virtual\_image\_context }
 
\
 
\hspace{1mm}  Ce fichier est utilisé par libvirt et fournis les contextes d'image qui sont disponibles dans la stratégie. La première entrée est le contexte de fichier image et la seconde est le contexte du contenu de l'image.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/x\_contexts }
 
\
 
\hspace{1mm}  Ce fichier fournis les contextes de sécurité par défaut pour l'extension de sécurité SELinux, décris dans selabel\_x.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/files/file\_contexts }
 
\
 
\hspace{1mm}  Ce fichier est géré par semodule et semanage et ne devrait pas être édités. Ce fichier est utilisé par des commandes comme setfiles, fixfiles, matchpathcon, restorecon pour relabéliser parties ou tout un système de fichier.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/files/file\_contexts.local }
 
\
 
\hspace{1mm}  Ce fichier est géré par semanage fcontext.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/files/file\_contexts.homedirs }
 
\
 
\hspace{1mm}  Ce fichier est géré par semodule et semanage et ne devrait pas être édité. Il est généré par genhomedircon et utilisé pour définir les contextes de sécurité dans les répertoires personnels.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/files/file\_contexts.subs[\_dist] }
 
\
 
\hspace{1mm}  Ces fichiers permettent des substitutions de noms de fichier pour les fonctions matchpatchcon(3) et selabel\_lookup(3).
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/files/media }
 
\
 
\hspace{1mm}  Ce fichier est utilisé pour mapper les types de média en un contexte de fichier.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge contexts/users/[seuser\_id] }
 
\
 
\hspace{1mm}  Ces fichiers optionnels sont nommés d'après les utilisateurs SELinux qu'ils représentent. Chaque fichier est utilisé pour assigner le contexte de sécurité correct à l'utilisateur, généralement durant le login.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge logins/<linuxuser\_id> }
 
\
 
\hspace{1mm}  Ces fichier optionnels sont utilisés par les application de login pour obtenir un username SELinux et un niveau basé sur l'UID GNU/Linux et le nom du service.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge users/local.users }
 
\
 
\hspace{1mm}  Généralement le fichier local.users n'est pas présent si semanage est utilisé pour gérer les utilisateurs. Ce fichier contient les définitions des utilisateurs locaux sous la forme de déclarations user.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Langage de stratégie SELinux }
 
\
 
\hspace{1mm}  Cette section est une référence des déclarations règles de langage de stratégie.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Langage de stratégie kernel }
 
\
 
\hspace{1mm}  Il y a 3 types de base de fichier source de stratégie qui peuvent contenir des déclarations et règle de langage. Ces 3 type sont:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} monolitique]{Simple fichier source qui contient toutes les déclarations. Par convention, il est appelé policy.conf et est compilé par checkpolicy.}
\item[\hspace{1mm} base]{Fichier source obligatoire qui supporte l'infrastructure modulaire. Toute la stratégie système peut être contenu dans ce fichier, cependant il est plus courant d'avoir des fichiers sources de modules chargeable séparés. Par convention ce fichier est appelé base.conf}
\item[\hspace{1mm} module]{Ces fichiers sources optionnels peuvent être chargés dynamiquement dans le magasin de stratégie. Par convention ces fichiers sont nommés d'après le module qu'ils représentent.}
\end{description}
 
\hspace{1mm}  Le tableau ci-dessous affiche l'ordre dans lequel les déclarations devraient apparaître dans les fichiers sources
\vspace{5mm} \\
 
 
{\includegraphics[]{../images/selinux14.png}}
 
\hspace{1mm} La grammaire du langage définis les déclaration et règles qui peuvent être utilisées dans les types de fichier source. Pour souligner ces règles une indication est incluse dans chaque déclaration et règle pour montrer dans quelles circonstances elle est valide dans un fichier de stratégie source:
 
{\ttfamily
Monolithic | Base | Module\\ Yes/No | Yes/No | Yes/No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Règles de déclaration conditionnelle, optionnelle et requise }
 
\
 
\hspace{1mm} La grammaire spécifie quelles déclaration et règles peuvent être incluses dans les déclarations conditionnelles, optionnelles et requise. Pour souligner ces règles une indication est incluse dans chaque déclaration et règle pour montrer dans quelles circonstances chacune est valide dans un fichier de stratégie source:
 
{\ttfamily
if | optional | require\\ Yes/No | Yes/No | Yes/No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Déclarations MLS et composants MLS optionnels }
 
\
 
\hspace{1mm}  Quand MLS est activé, il y a d'autres déclaration qui nécessitent le composant MLS comme argument.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Informations générales }
 
\
 
\begin{description} \normalsize
\item[\hspace{1mm} 1]{Les identifiant peuvent généralement être de n'importe quelle longueur mais devraient être restreints aux caractères suivant: [a-zA-Z0-9\_]}
\item[\hspace{1mm} 2]{Un '\#' indique le début d'un commentaire}
\item[\hspace{1mm} 3]{Toutes les déclarations disponible dans la stratégie version 29 ont été incluses}
\item[\hspace{1mm} 4]{Quand plusieurs entrées source et cible sont affichés en une seul déclaration ou règle, le compilateur étend ces déclaration ou règles individuelles.}
\item[\hspace{1mm} 5]{Certaines déclarations peuvent être ajoutées à une stratégie via le magasin de stratégie en utilisant semanage.}
\item[\hspace{1mm} 6]{Les mots réservés sont:}
\end{description}
 
{\ttfamily
alias allow and attribute attribute\_role auditallow\\ auditdeny bool category cfalse class clone\\ common constrain ctrue dom domby dominance\\ dontaudit else equals false filename filesystem\\ fscon fs\_use\_task fs\_use\_trans fs\_use\_xattr genfscon h1\\ h2 identifier if incomp inherits iomemcon\\ ioportcon ipv4\_addr ipv6\_addr l1 l2 level\\ mlsconstrain mlsvalidatetrans module netifcon neverallow nodecon\\ not notequal number object\_r optional or\\ path pcidevicecon permissive pirqcon policycap portcon\\ r1 r2 r3 range range\_transition require\\ role roleattribute roles role\_transition sameuser sensitivity\\ sid source t1 t2 t3 target true type typealias\\ typeattribute typebounds type\_change type\_member types type\_transition\\ u1 u2 u3 user validatetrans version\_identifier\\ xor default\_user default\_role default\_type default\_range low\\ high low\_high\\
}
\vspace{8mm}
 
\begin{description} \normalsize
\item[\hspace{1mm} 7]{La table ci-dessous indique quelles déclarations et règles sont permises dans chaque type de fichier source, et si la déclaration est valide dans une construction if/else, optional \verb|{|rule\_list\verb|}|, ou require \verb|{|rule\_list\verb|}|}
\end{description}
 
{\includegraphics[]{../images/selinux15.png}}
 
{\includegraphics[]{../images/selinux16.png}}
 
\vspace{1cm}{\huge policycap }
 
\
 
\hspace{1mm} Permet d'activer/désactiver de nouvelles capacibility dans le kernel via la stratégie. La déclaration de la définition est:
 
{\ttfamily
policycap <capability>;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge default\_user }
 
\
 
\hspace{1mm} Sélectionne l'utilisateur par défaut depuis le contexte source ou cible en calculant un nouveau contexte pour un objet de classe définie. La déclaration est:
 
{\ttfamily
default\_user <class> <source|target>;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge default\_role }
 
\
 
\hspace{1mm} Sélectionne le rôle par défaut depuis le contexte source ou cible en calculant un nouveau contexte pour un objet de classe définie. La déclaration est:
 
{\ttfamily
default\_role <class> <source|target>;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge default\_type }
 
\
 
\hspace{1mm} Sélectionne le type par défaut depuis le contexte source ou cible en calculant un nouveau contexte pour un objet de classe définie. La déclaration est:
 
{\ttfamily
default\_type <classe> <source|target>;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge default\_range }
 
\
 
\hspace{1mm} Sélectionne la plage ou le niveau depuis le contexte source ou cible en calculant un nouveau contexte pour un objet de classe définie. La déclaration est:
 
{\ttfamily
default\_range <class> <source|target> <low,high,low\_high>;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge user }
 
\
 
\hspace{1mm} La déclaration user déclare un identifiant utilisateur SELinux dans la stratégie et l'associe à un ou plusieurs rôles. La déclaration permet également un niveau ou plage MLS pour contrôler le niveau de sécurité utilisateur. Il est également possible d'ajouter l'id de l'utilisateur SELinux en dehors de la stratégie avec 'semanage user' qui va associer l'utilisateur avec les rôles précédemment déclarés dans la stratégie. La déclaration est:
 
{\ttfamily
user <seuser\_id> roles <role\_id>;\\ ou pour une stratégie MCS/MLS:\\ user <seuser\_id> roles <role\_id> level <mls\_level> range <mls\_range>;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge role }
 
\
 
\hspace{1mm} La déclaration role déclare un identifiant de rôle ou associe un identifiant de rôle à un ou plusieurs types. Lorsqu'il y a plusieurs déclaration role déclarant le même rôle, le compilateur associe les types additionnels avec le rôle. La déclaration est:
 
{\ttfamily
role <role\_id>;\\ role <role\_id> types <type\_id>;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|Yes|Yes\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge attribute\_role }
 
\
 
\hspace{1mm} Déclare un identifiant d'attribut de rôle qui peut être utilisé pour référrer à un groupe de rôles. La déclaration est:
 
{\ttfamily
attribute\_role attribute\_id;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|Yes|Yes\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge roleattribute }
 
\
 
\hspace{1mm} Permet l'association de rôles précédemment déclarés et un ou plusieurs attribute\_roles précédemment déclarés. La déclaration est:
 
{\ttfamily
roleattribute role\_id attribute\_id;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge allow }
 
\
 
\hspace{1mm} allow vérifie si une requête pour changer de rôle est permise, si c'est le cas, peut ensuite être suivie par un role\_transition. La déclaration est:
 
{\ttfamily
allow from\_role\_id to\_role\_id;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge role\_transition }
 
\
 
\hspace{1mm} Spécifie qu'une transition de rôle est requise. La déclaration est:
 
{\ttfamily
role\_transition current\_role\_id type\_id : class new\_role\_id;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge type }
 
\
 
\hspace{1mm} Déclare l'identifiant de type et des identifiants optionnels alias ou attribute associés. La déclaration est:
 
{\ttfamily
type type\_id \texttt{[}alias alias\_id\texttt{]} \texttt{[}, attribute\_id\texttt{]};\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|No|Yes\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge attribute }
 
\
 
\hspace{1mm} Déclare un identifiant qui peut ensuite être utilisé pour référrer à un groupe d'identifiant de type. La déclaration est:
 
{\ttfamily
attribute attribute\_id;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|Yes|Yes\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge typeattribute }
 
\
 
\hspace{1mm} Permet l'association des types précédemment déclarés à un ou plusieurs attributs déclarés. La déclaration est:
 
{\ttfamily
typeattribute type\_id attribute\_id;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge typealias }
 
\
 
\hspace{1mm} Permet l'association d'un type précédemment déclaré à un ou plusieurs identifiants alias (la déclaration type est une alternative). La déclaration est:
 
{\ttfamily
typealias type\_id alias alias\_id;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge permissive }
 
\
 
\hspace{1mm} Permet au domaine nommé d'être lancé en mode permissive au lieu de lancer tous les domaines SELinux en mode permissive. La déclaration est:
 
{\ttfamily
permissive type\_id;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge type\_transition }
 
\
 
\hspace{1mm} Spécifie le type par défaut à utiliser pour la transition de domaine ou la création d'objet. Noter qu'une règle allow doit être utilisée pour autoriser la transition. La déclaration est:
 
{\ttfamily
type\_transition source\_type target\_type : class default\_type object\_name;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: Yes|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge type\_change }
 
\
 
\hspace{1mm} Spécifie un type par défaut en relabélisant un objet existant. Noter qu'une règle allow doit être utilisée pour autoriser l'accès. La déclaration est:
 
{\ttfamily
type\_change source\_type target\_type : class change\_type;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: Yes|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge type\_member }
 
\
 
\hspace{1mm} Spécifie un type par défaut en créant un objet polyinstancié. Noter qu'une règle allow doit être utilisée pour autoriser l'accès. La déclaration est:
 
{\ttfamily
member\_type source\_type target\_type : class member\_type;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: Yes|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge typebounds }
 
\
 
\hspace{1mm} Définis une relation hiérarchique entrée les domaines où le domaine lié ne peut pas avoir plus de permission que son domaine parent. La déclaration est:
 
{\ttfamily
typebounds bounding\_domain bounded\_domain;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge allow }
 
\
 
\hspace{1mm} Vérifie si l'opération entre le source\_type et target\_type sont permis pour la classe et les permissions définies. La déclaration est:
 
{\ttfamily
allow source\_type target\_type : class perm\_set;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: Yes|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge dontaudit }
 
\
 
\hspace{1mm} Stoppe l'audit des messages de refus. Celà aide à gérer les audits en excluant des évènements connus. La déclaration est:
 
{\ttfamily
dontaudit source\_type target\_type : class perm\_set;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: Yes|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge auditallow }
 
\
 
\hspace{1mm} Audit l'évènement comme un enregistrement utile pour l'audit. Noter que cette règle ne fait qu'auditer l'évènement. Une règle allow est requise. La déclaration est:
 
{\ttfamily
auditallow source\_type target\_type : class perm\_set;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: Yes|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge neverallow }
 
\
 
\hspace{1mm} Spécifie qu'une règle allow ne doit pas être générée pour l'opération, même si elle a été autorisée précédemment. La déclaration est:
 
{\ttfamily
neverallow source\_type target\_type : class perm\_set;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge class }
 
\
 
\hspace{1mm} Hérite et/ou associe les permisdsion à une classe précédemment déclarées. Les classe sont déclarée comme suit:
 
{\ttfamily
class class\_id\\ puis\\ class class\_id \texttt{[} inherits common\_set \texttt{]} \texttt{[} \{ perm\_set \} \texttt{]}\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|Yes\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge common }
 
\
 
\hspace{1mm} Déclare un identifiant commun et associe une ou plusieurs permissions communes. La déclaration est:
 
{\ttfamily
common common\_id \{ perm\_set \}\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge bool }
 
\
 
\hspace{1mm} Définis un identifiant booléen et son état initial utilisable dans une déclaration if. La déclaration est:
 
{\ttfamily
bool bool\_id default\_value;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|Yes|Yes\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge if }
 
\
 
\hspace{1mm} Utilisé pour former un block conditionnel de déclaration et règles qui sont forcés en fonction d'un ou plusieurs identifiants booléen. La déclaration est:
 
{\ttfamily
if (conditional\_expression) \{ true\_list \} \texttt{[} else \{ false\_list \} \texttt{]}\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge constrain }
 
\
 
\hspace{1mm} permet de restreindre les permissions pour les classes objet spécifiés en utilisant des expressions booléenness couvrant les types, role et users source et cible. La déclaration est:
 
{\ttfamily
constrain class perm\_set expression;\\ \hspace{2mm}\\ expression est définis comme suit:\\ ( expression : expression )\\ | not expression\\ | expression and expression\\ | expression or expression\\ | u1 op u2\\ | r1 role\_op r2\\ | t1 op t2\\ | u1 op names\\ | u2 op names\\ | r1 op names\\ | r2 op names\\ | t1 op names\\ | t2 op names\\ \hspace{2mm}\\ u1, r1, t1 = user, role, type source\\ u2, r2, t2 = user, role, type cible\\ \hspace{2mm}\\ op : == | !=\\ role\_op : == | != | eq | dom | domby | incomp\\ names : name | \{ name\_list \}\\ name\_list : name | name\_list name\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge validatetrans }
 
\
 
\hspace{1mm} Seul les classes objets lié au fichier sont supportés par cette déclaration et est utilisée pour contrôler la capacité de changer le contexte de sécurité des objets. La déclaration est:
 
{\ttfamily
validatetrans class expression;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge mlsconstrain }
 
\
 
\hspace{1mm} Permet de restreindre les permissions pour les classes objets spécifiés en utilisant des expressions booléennes couvrant les types, rôle, utilisateurs source et cible et les niveaux de sécurité. La déclaration est:
 
{\ttfamily
mlsconstrain cluss perm\_set expression;\\ \hspace{2mm}\\ expression est définis comme suit:\\ ( expression : expression )\\ | not expression\\ | expression and expression\\ | expression or expression\\ | u1 op u2\\ | r1 role\_mls\_op r2\\ | t1 op t2\\ | l1 role\_mls\_op l2\\ | l1 role\_mls\_op h2\\ | h1 role\_mls\_op l2\\ | h1 role\_mls\_op h2\\ | l1 role\_mls\_op h1\\ | l2 role\_mls\_op h2\\ | u1 op names\\ | u2 op names\\ | r1 op names\\ | r2 op names\\ | t1 op names\\ | t2 op names\\ \hspace{2mm}\\ u1, r1, t1, l1, h1 = user, role, type, low level, high level source\\ u2, r2, t2, l2, h2 = user, role, type, low level, high level cible\\ \hspace{2mm}\\ op : == | !=\\ role\_mls\_op : == | != | eq | dom | domby | incomp\\ names : name | \{ name\_list \}\\ name\_list : name | name\_list name\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge mlsvalidatetrans }
 
\
 
\hspace{1mm} Équivalent MLS de validatetrans et est seulement utilisé pour les classes objets liées aux fichiers, et permet de contrôler la capacité de changer le contexte de sécurité des objets. La déclaration est:
 
{\ttfamily
mlsvalidatetrans class expression;\\ \hspace{2mm}\\ expression est définis comme suit:\\ ( expression : expression )\\ | not expression\\ | expression and expression\\ | expression or expression\\ | u1 op u2\\ | r1 role\_mls\_op r2\\ | t1 op t2\\ | l1 role\_mls\_op l2\\ | l1 role\_mls\_op h2\\ | h1 role\_mls\_op l2\\ | h1 role\_mls\_op h2\\ | l1 role\_mls\_op h1\\ | l2 role\_mls\_op h2\\ | u1 op names\\ | u2 op names\\ | r1 op names\\ | r2 op names\\ | t1 op names\\ | t2 op names\\ | u3 op names\\ | r3 op names\\ | t3 op names\\ \hspace{2mm}\\ u1, r1, t1, l1, h1 = ancien user, role, type, low level, high level\\ u2, r2, t2, l2, h2 = nouveau user, role, type, low level, high level\\ u3, r3, t3, l3, h3 = Processus user, role, type, low level, high level\\ \hspace{2mm}\\ op : == | !=\\ role\_mls\_op : == | != | eq | dom | domby | incomp\\ names : name | \{ name\_list \}\\ name\_list : name | name\_list name\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Déclarations MLS }
 
\
 
\hspace{1mm} L'extension de stratégie MLS ajoute un composant de contexte de sécurité additionnel qui consiste des entrées suivantes:
 
{\ttfamily
user:role:type:sensitivity\texttt{[}:category,...\texttt{]}= sensitivity \texttt{[}:category,...\texttt{]}\\
}
\vspace{8mm}
 
\hspace{1mm}  Ils consistent d'une sensibilité hiérarchique obligatoire et de catégories non-hiérarchiques. La combinaison des 2 comprennent un niveau ou un niveau de sécurité. En fonction des circonstances, cela peut être un niveau définis ou une plage.
\vspace{5mm} \\
 
 
\hspace{1mm}  Pour que les niveaux de sécurité soient plus significatifs, il est possible d'utiliser le service setransd pour les traduire au format humain.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge sensitivity }
 
\
 
\hspace{1mm} Définis la sensibilité de stratégie MLS et les alias optionnels. La déclaration est:
 
{\ttfamily
sensitivity sens\_id \texttt{[}alias sensitivityalias\_id ...\texttt{]};\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|Yes\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge dominance }
 
\
 
\hspace{1mm} Quand plus d'une déclaration sensitivity sont définies dans une stratégie, une déclaration dominance est requise pour définir la hiérarchie actuelle entre toutes les sensibilités. La déclaration est:
 
{\ttfamily
dominance \{ sensitivity\_id ... \}\\ \hspace{2mm}\\ La liste est dans l'ordre du plus faible au plus haut.\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge category }
 
\
 
\hspace{1mm} La déclaration category définis les identifiants de catégorie de stratégie MLS et les alias optionnels. La déclaration est:
 
{\ttfamily
category category\_id \texttt{[}alias categoryalias\_id ... \texttt{]};\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|Yes\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge level }
 
\
 
\hspace{1mm} Permet de combiner des sensibilité et les catégories précédemment déclarées en un niveau de sécurité. Noter qu'il doit y avoir seulement une déclaration level pour chaque déclaration sensitivity. La déclaration est:
 
{\ttfamily
level sensetivity\_id \texttt{[} :category\_id \texttt{]};\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge range\_transition }
 
\
 
\hspace{1mm} Principalement utilisée par le processus init ou les commandes d'administration pour s'assurer que les processus fonctionnent avec leur plage MLS correct. La déclaration est:
 
{\ttfamily
range\_transition source\_type target\_type : class new\_range;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|Yes\\ if | optional | require: No|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge sid }
 
\
 
\hspace{1mm} Déclare l'identifiant SID actuel et est définis au démarrage d'un fichier source. la délaration sert également à initialiser un contexte de sécurité au SID. La déclaration est:
 
{\ttfamily
sid sid\_id\\ sid sid\_id context\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge fs\_use\_xattr }
 
\
 
\hspace{1mm} Utilisé pour allouer un contexte de sécurité aux systèmes de fichiers qui supportent l'attribut étendu security.selinux. Le labéling est persistant pour les systèmes de fichiers qui supportent ces attributs étendus, et le contexte de sécurité est ajouté à ces fichiers et répertoires par les commandes SELinux. La déclaration est:
 
{\ttfamily
fs\_use\_xattr fs\_name fs\_context;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge fs\_use\_task }
 
\
 
\hspace{1mm} Utilisé pour allouer un contexte de sécurité à un pseudo système de fichier qui supporte les services liés aux tâches tels que les pipes et les sockets. La déclaration est:
 
{\ttfamily
fs\_use\_task fs\_name fs\_context;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge fs\_use\_trans }
 
\
 
\hspace{1mm} Utilisé pour allouer un contexte de sécurité à des pseudo systèmes de fichier tels que les pseudo terminaux et les objets temporaires. Le contexte assigné est dérivé du processus créateur et du type de systèmed de fichier basé sur les règles de transition. La déclaration est:
 
{\ttfamily
fs\_use\_trans fs\_name fs\_context;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge genfscon }
 
\
 
\hspace{1mm} Utilisé pour allouer un contexte de sécurité aux systèmes de fichiers qui ne supportent pas d'autres déclaration de labéling. Généralement un système de fichier a un seul contexte de sécurité par défaut assigné par genfscon depuis '/' qui est ensuit hérité par tous les fichiers et répertoires dans ce système de fichier. /proc est l'exception où les répertoires peuvent être labélisés avec un contexte spécifique. La déclaration est:
 
{\ttfamily
genfscon fs\_name partial\_path fs\_context\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge netifcon }
 
\
 
\hspace{1mm} Utilisé pour labéliser les objets d'interface réseaux (ex: eth0). La déclaration est:
 
{\ttfamily
netifcon netif\_id netif\_context packet\_context\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge nodecon }
 
\
 
\hspace{1mm} Utilisé pour labéliser les objets d'adresse réseaux qui représentent des adresse IPv4 et IPv6 et des masques réseaux. La déclaration est:
 
{\ttfamily
nodecon subnet netmask node\_context\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge portcon }
 
\
 
\hspace{1mm} Utilisé pour labéliser les ports udp ou tcp. La déclaration est:
 
{\ttfamily
portcon protocol port\_number port\_context\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge module }
 
\
 
\hspace{1mm} Cette déclaration est obligatoire pour les modules chargeables et doit être la première ligne d'un fichier source de stratégie. L'identifiant ne doit pas être en conflit avec d'autres noms de module dans la stratégie. La déclaration est:
 
{\ttfamily
module module\_name version\_number;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge require }
 
\
 
\hspace{1mm} La déclaration require est utilisée pour 2 raisons. La première est dans les fichiers sources de module pour indiquer quels composants de stratégie sont requis depuis un fichier de sources externe. Ensuite dans un fichier source de stratégie de base, si précédé par "optional", indique quels composants de stratégie sont requis depuis un fichier source externe. La déclaration est:
 
{\ttfamily
require \{ rule\_list \}\\ \hspace{2mm}\\ Monolithic | Base | Module: No|Yes|Yes\\ if | optional | require: Yes|Yes|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge optional }
 
\
 
\hspace{1mm} UTilisé pour indiquer quelles déclarations de startégie peuvent ou non être présent dans la stratégie compilée finale. Les déclarations seront inclus dans la stratégie seulement si toutes les déclarations optional peuvent être étendues, ce qui est généralement accomplis en utilisant une déclaration require. La déclaration est:
 
{\ttfamily
optional \{ rule\_list \} \texttt{[} else \{ rule\_list \} \texttt{]}\\ \hspace{2mm}\\ Monolithic | Base | Module: No|Yes|Yes\\ if | optional | require: Yes|Yes|Yes\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge iomemcon }
 
\
 
\hspace{1mm} La déclaration sid déclare l'identifiant SID actuel et est définis au début d'un fichier source de stratégie. La déclaration est:
 
{\ttfamily
iomemcon addr context;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge ioportcon }
 
\
 
\hspace{1mm} La déclaration est:
 
{\ttfamily
ioportcon port context;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge pcidevicecon }
 
\
 
\hspace{1mm} La déclaration est:
 
{\ttfamily
pcidevicecon pci\_id context;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge pirqcon }
 
\
 
\hspace{1mm} la déclaration est:
 
{\ttfamily
pirqcon irq context;\\ \hspace{2mm}\\ Monolithic | Base | Module: Yes|Yes|No\\ if | optional | require: No|No|No\\
}
\vspace{8mm}
\end{flushleft}
\end{document}
