# SELinux
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
## Répertoires
**/sys/fs/selinux** Le système de fichier SELinux qui interface avec le
service de sécurité du kernel.
**/etc/selinux** La configuration pour selinux
**/var/lib/selinux/‹SELINUXTYPE›/module** Modules de stratégie SELINUX
## Utilité
**-** 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
**-** 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.
**-** 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é.
**-** Si une application 'fait quelque chose" qui n'est pas permis par
stratégie, SELinux peut stopper ces actions
**-** 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.
**-** 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.
**-** 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.
**-** SELinux ne stoppe pas les fuites mémoire, ou débordement de
tampon, cependant il peut contenir les dommages qui peuvent être
faits.
**-** SELinux ne stop pas tous les virus/malware dans le système,
cependant il devrait limiter les dégats ou fuites qu'ils causent.
**-** SELinux ne stop pas les vulnérabilités, cependant, il peut limiter
leurs effets.
**-** 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.
**-** SELinux ne peut pas stopper ce qui est autorisé par stratégie,
donc un bon design est important.
## Composants du cœur SELinux
**-** Un sujet qui doit être présent pour déclencher une action à
prendre par un objet.
**-** Un gestionnaire d'objet qui connaît les actions requises pour la
ressource particulière et peut forcer ces actions
**-** 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é
**-** Une Stratégie de sécurité qui décris les règles utilisant le
language de stratégie SELinux
**-** Un cache de vecteur d'accès qui améliore les performances
système.
![Composants haut niveau du cœur SELinux](./images/selinux01.png)
![Architecture SELinux haut-niveau](./images/selinux02.png)
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:
**-** 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:
**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é.
**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.
**-** 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.
**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.** -
**Pour être capable de construire la stratégie, une source de stratégie
est requise, qui peut être fournie de 3 manières:**
**-** Un code source écrit en langage de stratégie SELinux.
**-** En utilisant la statégie référence, qui a des macros
haut-niveau pour définir les règles.
**-** En utilisant CIL (Common Intermediate Language).
****
**-** Pour pouvoir compiler les sources de stratégie puis les charger
dans le serveur de sécurité, un certains nombre d'outils sont requis
**-** 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.
**-** 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.
**-** SELinux supporte les services réseaux.
## Mandatory Access Control (MAC)
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:
**-** Les sujets sont des processus
**-** Les objets sont des ressources système tels que des fichiers,
sockets, etc.
**-** Les attributs de sécurité sont des contextes de sécurité
**-** 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.
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:
![Traitement d](./images/selinux03.png)
SELinux supporte 2 formet de MAC:
**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
**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é.
Les services MLS/MCS sont utilisés pour maintenir une séparation
d'applications, par exemple:
**-** Les machines virtuelles utilisent les catégories MCS pour
permettre à chaque VM de se lancer dans son propre domaine.
**-** 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.
## Utilisateurs SELinux
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.
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.
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.
Il est possible d'ajouter des contraintes et limites dans les
utilisateurs SELinux.
## RBAC
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.
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'.
Il est possible d'ajouter des contraintes et limites sur les rôles.
![RBAC](./images/selinux04.png)
## Type Enforcement
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.
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.
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.
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).
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).
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.
Le type SELinux est le troisième composant d'un contexte de sécurité
et par convention les types SELinux se terminent par '\_t'.
## Contraintes
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:
allow unconfined\_t ext\_gateway\_t : process transition;
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:
constrain process transition ( r1 == r2 );
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.
## Limites
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.
## Contexte de sécurité
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.
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.
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:
user:role:type\[:range\]
**user** L'identité de l'utilisateur SELinux. Peut être associé à un ou
plusieurs rôles que l'utilisateur SELinux est autorisé à utiliser
**role** Le rôle SELinux. Cela peut être associé à un ou plusieurs types
que l'utilisateur SELinux est autorisé à accéder
**type** Quand un type est associé avec un processus, il définis quels
processus ( ou domaines ) l'utilisateur SELinux ( le sujet ) peut
accéder.
**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
:
**-** 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
**-** 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)
Cependant, noter que:
**1** les décisions d'accès au regard du sujet utilisent tous les
composant du contexte de sécurité.
**2** Les décisions d'accès à un objet utilise les composant comme
suit:
**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)
**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.
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
)
LABEL PID TTY 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
Exemple de contexte de sécurité
d'objet:
system\_u:object\_r:in\_queue\_t /usr/message\_queue/in\_queue
system\_u:object\_r:out\_queue\_t /usr/message\_queue/out\_queue
Il y a les contextes de sécurité d'objet de file de message pris depuis
la commande ls
-Z:
/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
## Sujets
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.
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:
**1.** Un processus en cours de fonctionnement est un sujet parce il
créé un flux d'informations ou peut changer l'état système
**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.
Dans SELinux les sujets peuvent être:
**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).
**untrusted** Tout le reste
****
## Objets
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é.
## Classes objet et permissions
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.
![Classe objet = ](./images/selinux05.png)
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.
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.
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.
## Autoriser un processus à accéder aux ressources
C'est un simple exemple qui tente d'expliquer 2 points:
**1.** Comment un processus reçois la permission d'utiliser une
ressource
**2.** En utilisant la classse objet 'process', montrer qu'un processus
peut être décris comme un processus ou un objet.
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.
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é:
allow Rule | source\_domain | target\_type : classs | permission
allow unconfined\_ ext\_gateway\_t : process transition;
**allow** Défini une règle allow
**unconfined\_t** Le domaine source (ou sujet) dans ce cas le shell qui
souhaite exécuter l'application gateway
**ext\_gateway\_t** L'objet cible, l'instance objet du processus
gateway
**process** La classe objet de la cible
**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
## labeliser les objets
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:
**1.** Ils héritent leur labels du processus ou objet parent
**2.** Le type de stratégie, rôle et plage de transition permettent un
label différent.
**3.** Les applications gérant SELinux peuvent forcer un nouveau label
(avec approbation des stratégies) en utilisant les fonctions de l'API
libselinux
**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
**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.
Le langage de stratégie SELinux supporte les déclaration de
labélisation pour les services fichier et réseau.
La labélisation des systèmes de fichier qui implémentent les
attributs étendus sont supportés par SELinux en utilisant:
**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.
**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.
**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.
Les attributs étendus contenant le contexte SELinux d'un fichier peut
être vu par les commande ls -Z et getfattr.
## Copier et déplacer des fichiers
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:
**Copie d'un fichier** - prend le label du nouveau répertoire
**Déplacement d'un fichier** - Conserve le label du fichier
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.
## Labéliser des sujets
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 **user**,
**role**, et **type**, et gère leur scope **role\_allow**, et
**constrain**, et gère leur transition **type\_transition**,
**role\_transition** et **range\_transition**.
## Réutilisation d'objet
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.
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.
## Calculer les contextes de sécurité
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é.
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.
## Calcule de contexte de sécurité pour les objets Kernel
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.
Les processus héritent de leur contexte de sécurité comme suit:
**1.** Lors d'un fork, un processus hérite du contexte de sécurité de
son créateur/parent
**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.
**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.
Le comportement par défaut pour le label de fichier (actuellement les
inodes qui consistent des classes suivantes:
**1.** Le composant utilisateur est hérité du processus créateur
**2.** Le composant rôle est généralement par défaut object\_r
**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
**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
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.
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=.
## Descripteurs de fichier
Hérite du label de son créateur/parent.
## Systèmes de fichier
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:
**fs\_use\_task pipefs system\_u:object\_r:fs\_t:s0**
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:
**a)** Rechercher le nom du système de fichier dans la stratégie
(pipefs)
**b)** Si présent, obtenir sont comportement (fs\_use\_task)
**c)** Puis obtenir le contexte de sécurité alloué
(system\_u:object\_r:fs\_t:s0)
si le comportement est définis par fs\_use\_task, alors le système de
fichier sera labélié comme suit:
Notes:
**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
**2.** Il y a des points de montages pour allouer différents types de
contexte: context=, fscontext=, defcontext= et rootcontext=
## nfsv4
Si le label NFS est implémenté via le support xattr, la création des
inodes sont créés comme décris ci-dessus
## sockets INET
Si un socket est créé par l'appel socket(3), il est labélisé comme
suit:
**1.** Le composant utilisateur hérite du processus créateur
**2.** Le composant rôle hérite du processus créateur
**3.** Le composant type hérite du processus créateur si aucune règle
type\_transition n'est spécifié dans la stratégie
**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
## IPC
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:
**1.** Le composant utilisateur hérite du processus émetteur
**2.** Le composant rôle hérite du processus émetteur
**3.** Le composant type hérite du processus émetteur si aucune règle
type\_transition n'est spécifiée dans la stratégie
**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
## Sémaphores
Hérite du label de son créateur/parent
## Mémoire partagée
Hérite du label de son créateur/parent
## Clés
Hérite du label de son créateur/parent
## Transition d'objet et de domaine
La déclaration type\_transition est utilisée pour:
**1.** La transition d'un processus d'un domaine à un autre (une
transition de domaine)
**2.** La transition d'un objet d'un type à un autre (une transition
d'objet)
## Transition de domaine
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:
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:
type\_transition unconfined\_t secure\_services\_exec\_t : process
ext\_gateway\_t;
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:
allow crond\_t self : process setexec;
Cependant, avant toute transition de domaine la stratégi doit
spécifier que:
**1.** Le domaine source a la permission de transiter dans le domaine
cible
**2.** Le binaire de l'application doit être exécutable dans le domaine
source
**3.** Le binaire de l'application doit avoir un point d'entrée dans le
domaine cible
La déclaration type\_transition suivante est un exemple pour expliquer
le processus de
transition:
type\_transition | source\_domain | target\_type | class |
target\_domain;
type\_transition unconfined\_t secure\_services\_exec\_t : process
ext\_gateway\_t;
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.
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ù:
**1.** Le domaine nécessite la permission de transiter dans le domaine
ext\_gateway\_t:
**allow unconfined\_t : process transition;**
**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 { execute read
getattr };
**3.** Le fichier exécutable doit avoir un point d'entrée dans le
domaine ext\_gateway\_t:
**allow ext\_gateway\_t secure\_services\_exec\_t : file entrypoint;**
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.
![Transition de domaine](./images/selinux06.png)
## Règles de type forcé
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:
type\_transition unconfined\_t secure\_services\_exec\_t : process
ext\_gateway\_t;
et la déclaration int\_gateway\_t
serait:
type\_transition unconfined\_t secure\_services\_exec\_t : process
int\_gateway\_t;
Cependant, en liant ces 2 modules dans la stratégie, l'erreur suivante
se
produit:
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\!
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:
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;
et le module int\_gateway\_t a les déclarations
suivantes:
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;
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é.
Pour résoudre cela, il a été décidé:
**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: **secure\_server 99999**
**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: **runcon -t int\_gateway\_t -r message\_filter\_r
secure\_server 1111**
La commande runcom utilise libselinux pour vérifier le contexte
courant et définir le nouveau contexte.
d'autres manières de résoudre ce problème sont:
**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.
**2.** Utiliser des noms différents pour les fichiers exécutables du
serveur et s'assurer qu'ils ont un type différent
**3.** Implémenter la stratégie sur le modèle de la section templace
macro.
## Transition d'objet
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:
type\_transition ext\_gateway\_t in\_queue\_t:file in\_file\_t;
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:
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 ..
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:
type\_transition | source\_domain | target\_domain : object |
default\_type;
type\_transition ext\_gateway\_t in\_queue\_t : file in\_file\_t;
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.
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ù:
1\. le domaine source a la permission d'ajouter des entrées fichier dans
le répertoire:
**allow ext\_gateway\_t in\_queue\_t : dir { write search add\_name
);**
2\. Le domaine source a la permission de créer des entrées fichiers:
**allow ext\_gateway\_t in\_file\_t : file ( write create getattr );**
3\. La stratégie peut ainsi s'assurer que les fichiers créé dans
in\_queue sont relabélisés:
**type\_transition ext\_gateway\_t in\_queue\_t : file in\_file\_t;**
Un exemple de sortie d'un répertoire:
**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 ..
\-rw-r--r-- root root unconfined\_u:object\_r:in\_file\_t Message-1
\-rw-r--r-- root root unconfined\_u:object\_r:in\_file\_t Message-2
## MLS et MCS
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.
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.
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.
![Nivaux de sécurité et flux de données](./images/selinux07.png)
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.
Cependant, comme la vie n'est pas simple:
**1.** Les processus et objets peuvent avoir une plage qui représente
les niveaux de sécurité faible et élevés
**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
**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é.
**4.** Les processus trustés peuvent avoir des privilèges qui les
autorisent à bypasser les règles BLP.
**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.
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.
## Niveaux de sécurité
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\].
Le niveau de sécurité consiste d'une sensibilité ou 0 ou plusieurs
entrées catégories: **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.
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).
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)
Les composants suivants sont utilisés pour définir les niveaux de
sécurité MLS/MCS dans le contexte de
sécurité:
user:role:type:sensibilité\[:catégorie,...\] -
sensibilité\[:catégorie,...\]
où:
**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.
**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.
**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.
## Traduire les niveaux
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.
## Gérer les niveaux de sécurité via les règles de dominance
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:
**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
**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
**L1 équivaut à L2** Si la sensibilité de 1 et égal à L2 et les
catégories de L1 et L2 sont les même.
**L1 est incomparable à L2** Si les catégories de L1 et L2 ne peuvent
être comparés.
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.
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.
![Niveaux de sécurité MLS](./images/selinux08.png)
![Déclarations mlsconstain](./images/selinux09.png)
**1.** Pour autoriser write-up, le niveau source (l1) doit être dominé
par le niveau cible (l2)
**2.** Pour autoriser read-down, le niveau source (l1) doit dominer le
niveau cible (l2)
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.
## Certification Common Criteria
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.
## Types de stratégie SELinux
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.
## Stratégie exemple
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.
## Stratégie référence
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.
La stratégie référence est utilisée par toutes les distributions
Linux, cependant, chaque distribution effectue des propres
changements.
## Fonctionnalité de stratégie basé sur le nom ou le type
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:
**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)
**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).
## Stratégie Monolitique
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.
## Stratégie à module chargeable
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:
**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
**2.** Des utilitaires pour compiler et lier les modules et les placer
dans un magasin de stratégie
**3.** Des utilitaires pour gérer les modules et les fichiers de
configuration associés dans le magasin de stratégie
## Stratégie optionnelle
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.
## Stratégie conditionnelle
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.
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.
## Stratégie binaire
É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›.
## Versions de stratégie
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.
## Mode permissif et forcé
SELinux a 3 modes d'opération majeurs:
**Enforcing** SELinux impose la stratégie chargée
**Permissive** SELinux charge la stratégie, mais ne l'impose pas.
Généralement utilisé pour les tests
**Disabled** SELinux n'est pas activé.
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: **semanage permissive -a
unconfined\_t**
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.
## Auditer les évènements SELinux
Pour SELinux il y a 2 types principaux d'évènements d'audit:
**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.
**2.** Évènements d'applications - Ils sont générés par les services
kernel SELinux et les applications compatibles SELinux.
Les messages d'évènement et d'audit sont généralement stockés dans un
de ces logs:
**1.** Le évènement SELinux du boot kernel sont loggés dans
/var/log/dmesg
**2.** /var/log/messdages contient les messages générés par SELinux
avant que le système d'audit soit chargé
**3.** /var/log/audit/audit.log contient les évènements qui prennent
place une fois le service d'audit chargé.
## Notes
**a)** Il n'est pas obligatoire pour les applications SELinux d'auditer
les évènements ni de les logger.
**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)
**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).
## Évènements d'audit AVC
Cette section décris le format général des messages d'audit AVC dans
audit.log.
**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
**msg** Contient le mot clé 'audit' avec un numéro de référence
**avc** Soit denied soit granted
**pid|comm** Si c'est une tâche, log le pid et le nom de l'exécutable
**capability** Si c'est un évènement de capability, log l'identifiant
**path|name|dev|ino** Si c'est en évènement de système de fichier, log
les informations spécifique
**laddr|lport|faddr|fport** Si c'est un évènement socket, log les
adresses/port source/destination
**path** Si c'est un évènement de fichier socket, log le chemin
**saddr|src|daddr|dest|netif** Si un évènement réseau, log les
adresses/port source/destination
**sauid|hostname|addr|terminal** Identifiant d'association de sécurité
IPSec
**resid|restype** Type et ID de ressource X-Windows
**scontext** Le contexte de sécurité de la ressource ou sujet
**tcontext** Le contexte de sécurité de la cible ou objet
**tclass** La classe objet de la cible ou objet
## Évènements d'audit SELinux général
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.
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.
MAC\_POLICY\_LOAD, USER\_MAC\_POLICY\_LOAD - ces évènements sont générés
quand la stratégie est
rechargée:
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=?'
MAC\_STATUS - Généré quand le mode SELinux est
changé:
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)
MAC\_CONFIG\_CHANGE - Généré quand setsebool a été lancé pour changer un
booléen.
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)
MAC\_UNLBL\_STCADD - Généré quand un label statique non-mappé est
ajouté
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)
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
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
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
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)
USER\_ROLE\_CHANGE - newrole(1) a été utilisé pour définir un nouveau
rôle qui n'est pas
valide
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'
## Support de la poly-instanciation
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:
**1.** SELinux a des fonctions libselinux et une règle de stratégie pour
supporter la poly-instanciation
**2.** La poly-instanciation des répertoires est une fonction de
GNU/Linux
**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
## Objects poly-instanciés
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.
## Support de la poly-instanciation dans PAM
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.
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.
Pour implémenter les répertoires poly-instanciés PAM exige que les
fichiers suivants soient configurés:
**1.** Une entrée pour le module pam\_namespace. F-20 a déjà ces entrées
dans /etc/pam.d/gdm-password.
**2.** Les entrées sont ajoutées dans /etc/security/namespace.conf et
définissent les répertoires à poly-instancier par PAM.
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.
## Fichier de configuration namespace.conf
Chaque ligne dans namespace.conf est formaté comme suit:
**polydir instance\_prefix method list\_of\_uids**
où:
**polydir** Chemin absolu du répertoire à poly-instancier. $USER
et $HOME sont remplacés
**instance\_prefix** Un préfixe utilisé pour construire le
chemin pour le répertoire poly-instancié. $USER et $HOME sont
remplacés
**method** Détermine a méthode de la poly-instanciation:
**user** La poly-instanciation est basée sur les noms
d'utilisateur
**level** La poly-instanciation est basée sur le nom
d'utilisateur et le niveau MLS
**context** La poly-instanciation est basée sur le nom
d'utilisateur et le contexte de sécurité
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.
## Exemple de configuration
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.
Exemple 1 -
method=user:
\#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
Se connecter en tant qu'utilisateur normal. Le processus PAM va
construire les répertoires poly-instanciés
suivant:
\# /tmp
/tmp/tmp-inst/myuser
\# /var/tmp
/var/tmp/tmp-inst/myuser
\# $HOME
/home/myuser/myuser.inst/myuser
Exemple 2 -
method=context
\#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
Se connecter en tant qu'utilisateur normal. Le processus PAM va
construire les répertoires poly-instanciés
suivant:
\# /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
## Support dans la stratégie référence
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.
## Processus de login PAM
Les application utilisées pour fournir des services de login (comme
gdm ou ssh) utilisent PAM pour fournir les services suivants:
**Gestion de compte:** Ce service gère les services tels que
l'expiration des mots de passe, et les services de login autorisés
**Gestion de l'authentification** Authentifie l'utilisateur ou le sujet
et définis les accréditifs
**Gestion des mots de passe** Gère les mises à jours de mot de passe
**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.
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:
**pam\_selinux\_permit.so** Autorise à des utilisateurs prédéfinis la
capacité de se logger sans fournir de mot de passe
**pam\_selinux.so open** Définis un contexte de sécurité pour
l'utilisation au login.
**pam\_selinux.so close** Réinitialise le contexte des programme login
au contexte par défaut
## LSM et SELinux
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:
**1.** SElinux
**2.** AppArmor
**3.** SMACK
**4.** Tomoyo
**5.** Yama
L'idée de base derrière LSM est de:
**-** Insérer des hooks de fonction de sécurité et des structures de
données de sécurité dans les divers services kernel.
**-** Autoriser l'enregistrement et l'initialisatio des services pour
les modules tiers de sécurité
**-** 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é
**-** Supporter des systèmes de fichier qui utilisent les attributs
étendus
**-** Consolider les capacités Linux dans un module optionnel
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
Les services kernel où LSM implémente les hooks et structures
sont:
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
Fichiers /proc/self/attr/ utilisé par les services kernel et
libselinux:
**current** (-rw-rw-rw) - Contient le contexte de sécurité du
processus
**exec** (-rw-rw-rw) - Définis le contexte de sécurité pour le prochain
appel exec
**fscreate** (-rw-rw-rw) - Définis le contexte de sécurité des nouveaux
fichiers créés
**keycreate** (-rw-rw-rw) - Définis le contexte de sécurité pour les
clés qui sont en cache dans le kernel
**prev** (-r--r--r-) - Contient le précédent contexte de sécurité
**sockcreate** (-rw-rw-rw) - Définis le contexte de sécurité pour les
nouveaux sockets créés
## Support réseau
SELinux supporte les types suivans de label réseau:
**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
**Réseau labélisé** Lorsque les labels sont passé aux systèmes distant
où ils peuvent être interprétés: IPSec et CIPSO
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:
**network\_peer\_controls** Toujours activé dans la stratégie
référence
**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.
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)
Pour supporter IPSec labélisé, les outils IPSec doivent être
installés (package ipsec-tools)
Il est également possible d'utiliser un service IPSec labélisé
alternatif, LibreSwan
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.
## SECMARK
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).
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:
**-** 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.
**-** 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.
**-** Un CONNSECMARK maque tous les paquets dans une session avec le
label approprié qui peut ensuite être utilisé pour forcer la
stratégie.
Exemple d'entrée dans la table security. Marquer tous les paquets:
**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**
Ces règles remplacent le contexte précédent avec la gateway interne ou
externe si le port 9999 ou 1111 est trouvé:
**iptables -t security -A INPUT -i lo -p tcp --dport 9999 -j SECMARK
--selctx system.user:object\_r:msg\_filter.ext\_gateway.packet:s0**
**iptables -t security -A INPUT -i lo -p tcp --sport 9999 -j SECMARK
--selctx system.user:object\_r:msg\_filter.ext\_gateway.packet:s0**
**iptables -t security -A INPUT -i lo -p tcp --dport 1111 -j SECMARK
--selctx system.user:object\_r:msg\_filter.int\_gateway.packet:s0**
**iptables -t security -A INPUT -i lo -p tcp --sport 1111 -j SECMARK
--selctx system.user:object\_r:msg\_filter.int\_gateway.packet:s0**
**iptables -t security -A INPUT -m state --state ESTABLISHED,RELATED -j
CONNSECMARK --save**
\# Flux de sortie
**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**
**iptables -t security -A OUTPUT -i lo -p tcp --dport 9999 -j SECMARK
--selctx system.user:object\_r:msg\_filter.ext\_gateway.packet:s0**
**iptables -t security -A OUTPUT -i lo -p tcp --sport 9999 -j SECMARK
--selctx system.user:object\_r:msg\_filter.ext\_gateway.packet:s0**
**iptables -t security -A OUTPUT -i lo -p tcp --dport 1111 -j SECMARK
--selctx system.user:object\_r:msg\_filter.int\_gateway.packet:s0**
**iptables -t security -A OUTPUT -i lo -p tcp --sport 1111 -j SECMARK
--selctx system.user:object\_r:msg\_filter.int\_gateway.packet:s0**
**iptables -t security -A OUTPUT -m state --state ESTABLISHED,RELATED -j
CONNSECMARK --save**
## NetLabel - Fallback labeling
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.
## NetLabel - CIPSO
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.
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:
**1.** 1 bit de type de tag qui autorise un maximum de 256 niveaux et
240 catégories
**2.** Une option non-traductible où les labels sont passés depuis/vers
les systèmes de manière inchangée.
**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.
## IPsec labélisé
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).
![Communications IPSec](./images/selinux10.png)
Basiquement il se produit:
**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
**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.
**3.** Une fois les SA négociés et validés, le lien devrait être
actif.
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.
Chaque SA partage les même paramètres cryptographiques tels que les
clés et protocoles ESP et AH.
La classe objet utilisée pour l'association d'un SA est 'association'
et les permissions disponibles comme suit:
**polmatch** Matche le contexte SPD (-ctx) à un domaine SELinux (qui est
contenu dans l'entrée -ctx SAD)
**recvfrom** Reçu depuis une association IPSec
**sendto** Envoyé à une association IPSec
**setcontext** Définis le contexte d'une association IPSec à la
création.
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.
## Exemples de configuration
Il y a 2 solutions disponibles:
**Outils IPSec** - setkey et racoon
**LibreSwan** - ipsec et pluto
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
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:
**-** racoon a cette valeur à 10
**-** pluto est configurable avec par défaut 32001. Pour intéropérer
avec racoon, ipsec.conf doit avoir: **secctx\_attr\_value = 10**
L'exemple suivant montre la configuration setkey commune pour définir
les entrées SPD et en exemple de configuration supportant racoon et
pluto:
Ajouter un label/contexte au SPD pour la boucle
locale:
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;
Configuration
racoon:
path include "/etc/racoon";
path pre\_shared\_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
path script "/etc/racoon/scripts";
sainfo anonymous
{
lifetime time 1 hour ;
encryption\_algorithm 3des, blowfish 448, rijndael ;
authentication\_algorithm hmac\_sha1, hmac\_md5 ;
compression\_algorithm deflate ;
}
Configuration
LibreSwan/pluto:
version 2.0
config setup
plutorestartoncrash=false
protostack=netkey
plutodebug="all"
secctx\_attr\_value = 32001
conn
labeled\_loopback\_test
auto=start
rekey=no
authby=secret
type=transport
left=127.0.0.1
right=127.0.0.1
ike=3des-sha1
phase2=esp
phase2alg=aes-sha1
loopback=yes
labeled\_ipsec=yes
policy\_label=unconfined.user:msg\_filter.role:msg\_filter.ext\_gateway.process:s0
leftprotoport=tcp
rightprotoport=tcp
## Support des machines virtuelles
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.
## Support QEMU/KVM
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.
## Support libvirt
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).
## Labéliser les images VM
Le **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:
**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)
**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)
**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.
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 (**image partagée**).
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:
**setsebool -P virt\_use\_execmem on**
Maintenant que l'image a été configurée comme partageable, le
processus d'initialisation commence:
**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)
**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)
**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.
Il est possible de définir les **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.
Dans la ressource XML,
ajouter:
...
‹/devices›
‹seclabel type='static' model='selinux' relabel='no'›
‹label›system\_u:system\_r:avirt\_t:s0:c1022,c1023‹/label›
‹/seclabel›
‹/domain›
## Services Sandbox
Fedora supporte les 3 type de service sandbox:
**1.** sandboxing non-GUI.
**2.** Sandboxing GUI utilisant le serveur Xephyr. Il permet l'isolation
d'application X via des serveurs Xephyr imbriqués.
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.
Noter que les services sandbox nécessitent le support MCS vu que les
catégories sont utilisées pour isoler les multiples sandbox.
**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.
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.
## Support X-Windows
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'.
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.
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.
![X-Server et le gestionnaire d](./images/selinux11.png)
Les composant majeur qui forment XSELinux sont:
**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).
**libselinux** La libairie fournie les interfaces nécessaire entre l'OM
les services userspaces SELinux, et les services kernel.
**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)
**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.
**XACE** X Access Control Extension peut être utilisé par d'autres
extensions de sécurité de contrôle d'accès, pas seulement SELinux.
**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
**X-clients** Ils se connectent au serveur X et sont généralement des
gestionnaires de fenêtre comme Gnome ou KDE.
## Polyinstanciation
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
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.
## Information de configuration
La stratégie référence a un booléen xserver\_object\_manager qui
active/désactive le module de stratégie X-Server.
Le gestionnaire d'objet est traité comme une extension X-server et
son opcode majeur peut être requêté avec la fonction Xlib
XQueryExtension.
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
Section "Module"
SubSection "extmod"
Option "SELinux mode enforcing"
EndSubSection
EndSection
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:
\# object\_type object\_name context
**selection PRIMARY system\_u:object\_r:clipboard\_xselection\_t:s0**
ou pour la polyinstanciation
**poly\_selection PRIMARY
system\_u:object\_r:clipboard\_xselection\_t:s0**
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.
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.
**Notes:**
**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.
**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.
## SE-PostgreSQL
L'extension sepgsql permet de labéliser les objets de base
PostgreSQL. Le labéling au niveau des entrées n'est plus supporté.
l'extension segpsql ajoute SELinux aux objets de base de données tels
que les tables, colonnes, views, fonctions, schemas et séquences.
![Information de contexte de sécurité de base de
données](./images/selinux12.png)
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é.
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
![Services SE-PostgreSQL](./images/selinux13.png)
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:
SECURITY LABEL \[ FOR provider \] ON
{
TABLE object\_name |
COLUMN table\_name.column\_name |
AGGREGATE agg\_name (agg\_type \[, ...\] ) |
DATABASE object\_name |
DOMAIN object\_name |
EVENT TRIGGER object\_name |
FOREIGN TABLE object\_name
FUNCTION function\_name ( \[ \[ argmode \] \[ argname \] argtype
\[, ...\] \] ) |
LARGE OBJECT large\_object\_oid |
\[ PROCEDURAL \] LANGUAGE object\_name |
ROLE object\_name |
SCHEMA object\_name |
SEQUENCE object\_name |
TABLESPACE object\_name |
TYPE object\_name |
VIEW object\_name
} IS 'label'
Quelques exemples:
**SECURITY LABEL ON SCHEMA test\_ns IS
'unconfined\_u:object\_r:sepgsql\_schema\_t:s0:c10';**
**SECURITY LABEL ON TABLE test\_ns.info IS
'unconfined\_u:object\_r:sepgsql\_table\_t:s0:c20';**
**SECURITY LABEL ON COLUMN test\_ns.info.user\_name IS
'unconfined\_u:object\_r:sepgsql\_table\_t:s0:c30';**
**SECURITY LABEL ON COLUMN test\_ns.info.email\_addr IS
'unconfined\_u:object\_r:sepgsql\_table\_t:s0:c40';**
## Fonctions SQL additionnelles
les fonctions suivantes ont été ajoutées:
**sepgsql\_getcon** Retourne le contexte de sécurité du client
**sepgsql\_mcstrans\_in(text con)** Traduit la plage du contexte en
format brut fournis par mcstransd
**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
## postgresql.conf
Le fichier postgresql.conf supporte les entrées additionnelles
suivante pour permettre et gérer SE-PostgreSQL:
Cette entrée est obligatoire pour active l'extension sepgsql
**shared\_preload\_libraries = 'sepgsql'**
Permet de personnaliser les entrées sepgsql
**custom\_variable\_classes = 'sepgsql'**
Permet de lancer sepgsql en mode permissive
**sepgsql.permissive = on**
ACtive les messages d'audit sans regarder les paramètres de la
stratégie
**sepgsql.debug\_audit = on**
pour voir ces paramètres, la déclaration SHOW peut être utilisée:
**SHOW sepgsql.permissive;**
**SHOW sepgsql.debug\_audit;**
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.
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.
**objoid** L'OID de l'objet pour lequel ce label est pertinent
**classoid** L'OID du catalogue système dans lequel cet objet apparaît
**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.
**provider** Fournisseur de label associé avec ce label. Actuellement
seul SELinux est supporté
**lael** Label de sécurité appliqué à cet objet
Ce sont des entrées prises depuis un 'SELECT \* FROM pg\_seclabel;'
d'une base de
test:
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
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:
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
## Support Apache
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
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.
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:
**L** Linux support SELinux
**A** Apache a un support partiel de SELinux
**P** PostgreSQL supporte SELinux avec SE-PostgreSQL
**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.
## mod\_selinux
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:
**1.** Un utitisateur envoie une requête HTTP à Apache qui nécessite les
services d'une application web
**2.** Apache reçois la requête et lance l'instance de l'application web
pour effectuer la tâche:
**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
**b)** Avec mod\_selinux activé, l'application web est lancée
avec le contexte de sécurité définis dans mod\_selinux.conf
L'application web quitte, redonnant le contrôle au serveur web qui
répond avec la réponse HTTP.
## Limites
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:
typebounds httpd\_t httpd\_child\_t;
allow httpd\_t etc\_t : file { getattr read };
allow httpd\_child\_t etc\_t : file { read write };
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.
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.
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'.
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:
**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"
**b)** setcon\_thread2\_example.c - ces fonctions sont similaire,
cependant il appel setcon depuis un thread
## Fichiers de configuration de SELinux
Cette section explique chaque fichier de configuration SELinux. Les
fichiers de configuration sont classés comme suit:
**configuration globale** - affecte la stratégie active et les
application supportant SELinux, utilitaires et commandes
**configuration de stratégie** - utilisés par une stratégie active
**configuration kernel** - localisé sous /sys/fs/selinux et reflète la
configuration courante
## Migration du magasin de stratégie
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:
Compiler et installer une base et 2 modules écrits en langage kernel
**checkmodule -o base.mod base.conf**
**semodule\_package -o base.pp base.mod -f base.fc**
**checkmodule -m ext\_gateway.conf -o ext\_gateway.mod**
**semodule\_package -o ext\_gateway.pp -m ext\_gateway.mod -f
gateway.fc**
**checkmodule -m int\_gateway.conf -o int\_gateway.mod**
**semodule\_package -o int\_gateway.pp -m int\_gateway.mod**
**semodule -s modular-test --priority 100 -i base.pp ext\_gateway.pp
int\_gateway.pp**
Compiler et installer un module écrit en CIL
**semodule -s modular-test --priority 400 -i custom/int\_gateway.cli**
Affiche la liste des modules:
**semodule -s modular-test --list-modules=full**
affiche un listing standard des modules
**semodule -s modular-test --list-modules=standard**
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.
## /etc/selinux/config
Ce fichier est obligatoire, sans lui, ou corrompu, aucune stratégie
SELinux n'est chargée et SELinux est désactivé.
## /etc/selinux/semanage.conf
Ce fichier contrôle la configuration et les actions de semanage et
semodule.
## /etc/selinux/restorecond\[-user\].conf
Ces fichiers contient les fichiers et répertoire que restorecond
surveille afin de corriger le contexte de sécurité
## /etc/selinux/newrole\_pam.conf
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
## /etc/sestatus.conf
Utilisé par sestatus pour lister les fichiers et processus dont le
contexte de sécurité doit être affiché avec -v.
## /etc/security/sepermit.conf
Fichier de configuration pour le module PAM pam\_sepermit
## Fichiers de configuration du magasin de stratégie
/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.
**modules/** le magasin a 2 fichiers de lock utilisés par libsemanage
pour gérer les magasin (semanage.read.LOCK et semanage.trans.LOCK)
**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.
**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
**modules/active/commit\_num** Fichier binaire utilisé par libsemanage
pour gérer les mises à jours dans le magasin.
**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:
**homedir\_template** Utilisé pour produire le fichier
file\_contexts.homedirs qui devient ensuite le fichier
contexts/files/file\_contexts.homedirs
**file\_contexts** Qui devient ensuite le fichier
contexts/files/file\_contexts
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.
homedir\_template
file\_contexts
Le format du fichier file\_contexts.template est comme
suit:
pathname\_regexp \[file\_type\] opt\_security\_context
**pathname\_regexp** Une entrée qui définis le chemin qui peut être une
expression régulière
**file\_type** Une des entrées optionnelles suivante: -b|c|d|p|l|s|-.
**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
Les mots clé qui peuvent être dans ce fichier sont:
**HOME\_ROOT** Remplacé par le répertoire racine des répertoires
personnels, normalement /home.
**HOME\_DIR** Répertoire des répertoires personnels utilisateurs, défaut
/home.
**USER** Remplacé par le user id
**ROLE** Remplacé par l'entrée 'prefix' du fichier de configuration
users\_extra qui correspond au user id des utilisateurs
SELinux.
## Exemple de file\_contexts.template
/. /.. /.config /.hcwd /.local system\_u:object\_r:default\_t:s0
/\[^/\]+ -- system\_u:object\_r:etc\_runtime\_t:s0
/a?quota\\.(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/\\.journal ‹‹none››
**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.
**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
**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.
**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.
**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
**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.
**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.
**modules/active/booleans.local** Ce fichier est créé et mis à jours par
semanage boolean et maintient les booléens
**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)
**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.
**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.
**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
**modules/active/preserve\_tunables** Ce fichier n'existe que si la
stratégie construite préserve les personnalisations.
**modules/active/disable\_dontaudit** Ce fichier n'existe que si la
stratégie construite en ayant désactivé les règles dontaudit
**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.
## Fichiers de configuration de stratégie
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è).
**policy/policy.29** Stratégie binaire chargée dans le kernel
**context/files/file\_contexts** Pour permettre au système de fichier
d'être relabelisé
**context/dbus\_contexts** Pour permettre au service de messagerie dbus
à fonctionner sous SELinux
**context/x\_contexts** Pour autoriser le service X-Windows à
fonctionner sous SELinux
## fichier seusers
Le fichier seusers est utilisé par les programes login et par les
utilisateurs GNU/Linux en utilisateurs SELinux. Une séquence de
connexion serait:
**-** En utiliser le userid GNU/Linux, recherche re selinux\_id dans ce
fichier. S'il n'est pas trouvé, utilise l'entrée \_\_default\_\_
**-** Pour déterminer le contexte à utiliser, lit
contexts/users/\[seuser\_id\]. S'il n'est pas présent:
**-** 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.
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.
## Fichiers booleans et booleans.local
Dépréciés et généralement non présent, ces fichiers gèrent les
booléens.
## booleans.subs\_dist
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 **policy\_bool\_name new\_name**.
## setrans.conf
Ce fichier est utilisé par mcstrands pour traduire les niveaux de
stratégies MCS/MLS en labels user friendly.
## secolor.conf
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.
## policy/policy.
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.
## contexts/customizable\_types
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é.
## contexts/default\_contexts
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.
## contexts/dbus\_contexts
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.
## contexts/default\_type
Le fichier permet aux applications comme newrole de sélectionner un
type par défaut pour un rôle si aucun n'est fournis.
## contexts/failsafe\_context
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.
## contexts/initrc\_context
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.
## contexts/lxc\_contexts
Ce fichier supporte le labéling des conteneurs lxc dans la librairie
libvirt. Le format est le
suivant:
process = "security\_context"
file = "security\_context"
content = "security\_context"
**process** Une entrée qui contient le contexte de sécurité de domaine
lxc
**file** contient le contexte de sécurité de fichier lxc
**content** Une entrée qui contient le contexte de sécurité de contenu
lxc
**sandbox\_kvm\_process**
**sandbox\_lxc\_process** Ces entrées peuvent être présents
## contexts/netfilter\_contexts
Ce fichier supporte le labeling Secmark pour netfilter/iptable. Il
n'est pas utilisé actuellement.
## contexts/removable\_context
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.
## contexts/securetty\_types
Utilisé par newrole pour trouver le type à utiliser avec les
périphériques tty en changeant les rôles ou niveaux.
## contexts/sepgsql\_contexts
Ce fichier contient les contextes de sécurité par défaut pour les
objets de base SE-PostgreSQL, décrit dans selabel\_db
## contexts/systemd\_contexts
Ce fichier contient les contextes de fichiers utilisé par les tâches
lancées via systemd. Le format est **service\_class =
security\_context**.Exemple:
runtime=system\_u:object\_r:systemd\_runtime\_unit\_file\_t:s0
## contexts/userhelper\_context
Ce fichier contient le contexte de sécurité par défaut utilisé par
les applications system-config-\*, lancés en root.
## contexts/virtual\_domain\_context
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.
## contexts/virtual\_image\_context
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.
## contexts/x\_contexts
Ce fichier fournis les contextes de sécurité par défaut pour
l'extension de sécurité SELinux, décris dans selabel\_x.
## contexts/files/file\_contexts
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.
## contexts/files/file\_contexts.local
Ce fichier est géré par semanage fcontext.
## contexts/files/file\_contexts.homedirs
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.
## contexts/files/file\_contexts.subs\[\_dist\]
Ces fichiers permettent des substitutions de noms de fichier pour les
fonctions matchpatchcon(3) et selabel\_lookup(3).
## contexts/files/media
Ce fichier est utilisé pour mapper les types de média en un contexte
de fichier.
## contexts/users/\[seuser\_id\]
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.
## logins/
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.
## users/local.users
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.
## Langage de stratégie SELinux
Cette section est une référence des déclarations règles de langage de
stratégie.
## Langage de stratégie kernel
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:
**monolitique** Simple fichier source qui contient toutes les
déclarations. Par convention, il est appelé policy.conf et est compilé
par checkpolicy.
**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
**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.
Le tableau ci-dessous affiche l'ordre dans lequel les déclarations
devraient apparaître dans les fichiers sources
![Déclarations de base et modules](./images/selinux14.png)
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:
Monolithic | Base | Module
Yes/No | Yes/No | Yes/No
## Règles de déclaration conditionnelle, optionnelle et requise
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:
if | optional | require
Yes/No | Yes/No | Yes/No
## Déclarations MLS et composants MLS optionnels
Quand MLS est activé, il y a d'autres déclaration qui nécessitent le
composant MLS comme argument.
## Informations générales
**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\_\]
**2** Un '\#' indique le début d'un commentaire
**3** Toutes les déclarations disponible dans la stratégie version 29
ont été incluses
**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.
**5** Certaines déclarations peuvent être ajoutées à une stratégie via
le magasin de stratégie en utilisant semanage.
**6** Les mots réservés
sont:
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
**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 {rule\_list}, ou require
{rule\_list}
![déclarations et règles de langage permis dans chaque type de fichier
source - 1](./images/selinux15.png)
![déclarations et règles de langage permis dans chaque type de fichier
source - 2](./images/selinux16.png)
## policycap
Permet d'activer/désactiver de nouvelles capacibility dans le kernel via
la stratégie. La déclaration de la définition
est:
policycap ‹capability›
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## default\_user
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:
default\_user ‹class› ‹source|target›
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## default\_role
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:
default\_role ‹class› ‹source|target›
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## default\_type
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:
default\_type ‹classe› ‹source|target›
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## default\_range
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:
default\_range ‹class› ‹source|target› ‹low,high,low\_high›
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## user
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:
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›
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|No|No
## role
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:
role ‹role\_id›
role ‹role\_id› types ‹type\_id›
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|Yes
## attribute\_role
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:
attribute\_role attribute\_id;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|Yes
## roleattribute
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:
roleattribute role\_id attribute\_id;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No
## allow
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:
allow from\_role\_id to\_role\_id;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No
## role\_transition
Spécifie qu'une transition de rôle est requise. La déclaration
est:
role\_transition current\_role\_id type\_id : class new\_role\_id;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No
## type
Déclare l'identifiant de type et des identifiants optionnels alias ou
attribute associés. La déclaration
est:
type type\_id \[alias alias\_id\] \[, attribute\_id\];
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|No|Yes
## attribute
Déclare un identifiant qui peut ensuite être utilisé pour référrer à un
groupe d'identifiant de type. La déclaration
est:
attribute attribute\_id;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|Yes
## typeattribute
Permet l'association des types précédemment déclarés à un ou plusieurs
attributs déclarés. La déclaration
est:
typeattribute type\_id attribute\_id;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No
## typealias
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:
typealias type\_id alias alias\_id;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No
## permissive
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:
permissive type\_id;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No
## type\_transition
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:
type\_transition source\_type target\_type : class default\_type
object\_name;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: Yes|Yes|No
## type\_change
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:
type\_change source\_type target\_type : class change\_type;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: Yes|Yes|No
## type\_member
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:
member\_type source\_type target\_type : class member\_type;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: Yes|Yes|No
## typebounds
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:
typebounds bounding\_domain bounded\_domain;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No
## allow
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:
allow source\_type target\_type : class perm\_set;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: Yes|Yes|No
## dontaudit
Stoppe l'audit des messages de refus. Celà aide à gérer les audits en
excluant des évènements connus. La déclaration
est:
dontaudit source\_type target\_type : class perm\_set;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: Yes|Yes|No
## auditallow
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:
auditallow source\_type target\_type : class perm\_set;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: Yes|Yes|No
## neverallow
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:
neverallow source\_type target\_type : class perm\_set;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No
## class
Hérite et/ou associe les permisdsion à une classe précédemment
déclarées. Les classe sont déclarée comme
suit:
class class\_id
puis
class class\_id \[ inherits common\_set \] \[ { perm\_set } \]
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|Yes
## common
Déclare un identifiant commun et associe une ou plusieurs permissions
communes. La déclaration
est:
common common\_id { perm\_set }
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## bool
Définis un identifiant booléen et son état initial utilisable dans une
déclaration if. La déclaration
est:
bool bool\_id default\_value;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|Yes
## if
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:
if (conditional\_expression) { true\_list } \[ else { false\_list } \]
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No
## constrain
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:
constrain class perm\_set expression;
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
u1, r1, t1 = user, role, type source
u2, r2, t2 = user, role, type cible
op : == | \!=
role\_op : == | \!= | eq | dom | domby | incomp
names : name | { name\_list }
name\_list : name | name\_list name
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## validatetrans
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:
validatetrans class expression;
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## mlsconstrain
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:
mlsconstrain cluss perm\_set expression;
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
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
op : == | \!=
role\_mls\_op : == | \!= | eq | dom | domby | incomp
names : name | { name\_list }
name\_list : name | name\_list name
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## mlsvalidatetrans
É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:
mlsvalidatetrans class expression;
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
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
op : == | \!=
role\_mls\_op : == | \!= | eq | dom | domby | incomp
names : name | { name\_list }
name\_list : name | name\_list name
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## Déclarations MLS
L'extension de stratégie MLS ajoute un composant de contexte de sécurité
additionnel qui consiste des entrées
suivantes:
user:role:type:sensitivity\[:category,...\]= sensitivity
\[:category,...\]
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.
Pour que les niveaux de sécurité soient plus significatifs, il est
possible d'utiliser le service setransd pour les traduire au format
humain.
## sensitivity
Définis la sensibilité de stratégie MLS et les alias optionnels. La
déclaration
est:
sensitivity sens\_id \[alias sensitivityalias\_id ...\];
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|Yes
## dominance
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:
dominance { sensitivity\_id ... }
La liste est dans l'ordre du plus faible au plus haut.
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## category
La déclaration category définis les identifiants de catégorie de
stratégie MLS et les alias optionnels. La déclaration
est:
category category\_id \[alias categoryalias\_id ... \];
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|Yes
## level
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:
level sensetivity\_id \[ :category\_id \];
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## range\_transition
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:
range\_transition source\_type target\_type : class new\_range;
Monolithic | Base | Module: Yes|Yes|Yes
if | optional | require: No|Yes|No
## sid
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:
sid sid\_id
sid sid\_id context
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## fs\_use\_xattr
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:
fs\_use\_xattr fs\_name fs\_context;
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## fs\_use\_task
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:
fs\_use\_task fs\_name fs\_context;
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## fs\_use\_trans
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:
fs\_use\_trans fs\_name fs\_context;
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## genfscon
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:
genfscon fs\_name partial\_path fs\_context
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## netifcon
Utilisé pour labéliser les objets d'interface réseaux (ex: eth0). La
déclaration
est:
netifcon netif\_id netif\_context packet\_context
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## nodecon
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:
nodecon subnet netmask node\_context
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## portcon
Utilisé pour labéliser les ports udp ou tcp. La déclaration
est:
portcon protocol port\_number port\_context
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## module
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:
module module\_name version\_number;
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## require
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:
require { rule\_list }
Monolithic | Base | Module: No|Yes|Yes
if | optional | require: Yes|Yes|No
## optional
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:
optional { rule\_list } \[ else { rule\_list } \]
Monolithic | Base | Module: No|Yes|Yes
if | optional | require: Yes|Yes|Yes
## iomemcon
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:
iomemcon addr context;
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## ioportcon
La déclaration
est:
ioportcon port context;
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## pcidevicecon
La déclaration
est:
pcidevicecon pci\_id context;
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No
## pirqcon
la déclaration
est:
pirqcon irq context;
Monolithic | Base | Module: Yes|Yes|No
if | optional | require: No|No|No