Apparence
Uubu.fr

Les systèmes Linux, l’open source, les réseaux, l’interopérabilité, etc.
« Il vaut mieux viser la perfection et la manquer que viser l’imperfection et l’atteindre. » (Bertrand Arthur William RUSSEL)
08 mai 2017




/etc/selinux/<SELINUXTYPE>/booleans

/etc/selinux/‹SELINUXTYPE›/booleans, booleans.local

Fichiers de configuration pour les booléens SELinux

   Le fichier booleans, si présent, contient les booléens pour supporter une distribution spécifique. booleans.local, si présent contient les booléens générés localement. Ces fichiers contiennent une liste de noms et leurs valeurs associés. Généralement ces fichiers ne sont pas présents (ils ont été dépréciés). Cependant s'il y a une application qui utilise les fonctions libselinux listés ci-dessous, ces fichiers peuvent être présents:

security_set_boolean_list(3)
security_load_booleans(3)

Format

   Ces fichiers ont le format suivant: boolean_name value
^
08 mai 2017




checkpolicy

checkpolicy

Compilateur de stratégie SELinux

   checkpolicy est un programme qui vérifie et compile une configuration de stratégie de sécurité SELinux dans une représentation binaire qui peuvent être chargée dans le kernel. Si aucun fichier d'entrée n'est spécifié, tente de lire policy.conf ou la stratégie.

OPTIONS

-b, --binary Lit un fichier de stratégie binaire existant au lieu d'un fichier policy.conf
-C, --cil Écrit un fichier de stratégie CIL au lieu d'un fichier binaire
-d, --debug Entre en mode debug une pour la stratégie chargée
-M, --mls ACtive la stratégie MLS en vérifiant et en compilant la stratégie
-o, --output filename Écrit un fichier de stratégie binaire au nom spécifié
-c policyvers Spécifie la version de la stratégie
-t, --target Spécifie la platform cible (selinux ou xen)
-U, --handle-unknown ‹action› Spécifie comment le kernel doit gérer les classes ou permissions inconnues (deny, alow ou reject)
^
08 mai 2017




/etc/selinux/<SELINUXTYPE>/contexts/customizable_types

/etc/selinux/‹SELINUXTYPE›/contexts/customizable_types

Fichier de configuration des types personnalisables SELinux

   Ce fichier contient une liste de types qui peuvent être personnalisés dans certaines applications. Généralement, c'est un type de contexte de fichier qui est définis sur les fichiers qui doivent être partagés dans certains domaines et où les administrateurs souhaitent gérer manuellement le type.

   L'utilisation de types personnalisables est déprécié en faveur de semanage, fcontext, etc. Cependant les application compatibles SELinux comme setfiles utilisent ces informations pour obtenir une liste de types en relation avec des fichiers qui ne devraient pas être relabélisés. Chaque ligne dans le fichier consiste d'un type qui peut être personnalisé

Exemple:
mount_loopback_t
public_content_rw_t
public_content_t
swapfile_t
sysadm_untrusted_content_t

^
04 mai 2017




/etc/selinux/<SELINUXTYPE>/contexts/default_contexts

/etc/selinux/‹SELINUXTYPE›/contexts/default_contexts

Fichier de configuration de contextes par défaut SELinux

   Ce fichier contient des entrée pour les application de login compatible SELinux. Chaque ligne consiste des éléments suivants:

  login_process user_login_process [user_login_process] ...

login_process Consiste d'une entrée role:type[:range] qui représente le contexte du processus de login définis dans la stratégie
user_login_process Consiste d'une ou plusieurs entrées role:type[:range] qui représentent le contexte du processus login utilisateur définis dans la stratégie.

Exemple


system_r:crond_t:s0 system_r:system_crond_t:s0
system_r:local_login_t:s0 user_r:user_t:s0 staff_r:staff_t:s0
system_r:remote_login_t:s0 user_r:user_t:s0
system_r:sshd_t:s0 user_r:user_t:s0
system_r:sulogin_t:s0 sysadm_r:sysadm_t:s0
system_r:xdm_t:s0 user_r:user_t:s0
^
04 mai 2017




/etc/selinux/<SELINUXTYPE>/contexts/default_type

/etc/selinux/‹SELINUXTYPE›/contexts/default_type

Fichier de configuration de type par défaut SELinux

   Ce fichier contient les entrées qui permettent aux application compatibles SELinux comme newrole de sélectionner un type par défaut pour un rôle s'il n'est pas fournis. Chaque ligne dans ce fichier a le format role:type où:

role Le rôle SELinux
type Le type de domaine qui est retourné pour ce rôle

Exemple


auditadm_r:auditadm_t
user_r:user_t
^
05 mai 2017




/etc/selinux/<SELINUXTYPE>/contexts/failsafe_context

/etc/selinux/‹SELINUXTYPE›/contexts/failsafe_context

Fichier de configuration de contexte par défaut

   Ce fichier permet aux applications compatible SELinux tel que PAM d'obtenir un contexte de login valide pour un administrateur si aucune entrée par défaut n'est trouvé. Le format consiste des éléments suivant:

  role:type[:range]

Exemple

unconfined_r:unconfined_t:s0
^
16 mai 2017




genhomedircon

genhomedircon

Générer des entrées de configuration de contexte de fichier SELinux pour les répertoires personnels

   genhomedircon est un script qui exécute semodule pour reconstruire la stratégie SELinux active (sans la recharger) et pour créer les labels pour chaque répertoire personnel basé ser les chemins retournés par getpwent. Ce script est généralement exécuté par semanage bien que cela peut être modifié par disable-genhomedircon=true dans semanage.conf.

^
07 mai 2017




/etc/selinux/<SELINUXTYPE>/contexts/users/local.users

/etc/selinux/‹SELINUXTYPE›/contexts/users/local.users

Fichier de configuration des utilisateurs locaux SELinux

   Ce fichier contient les définitions des utilisateurs locaux sous la forme de déclaration d'utilisateur en langage de stratégie et est déprécié et remplacé par les services semanage. Ce fichier consiste d'une ou plusieurs entrées terminée pas ';', au format: user seuser_id roles role_id [[level level] [range range]];

user seuser_id l'identifiant de l'utilisateur SELinux
roles role_id Un ou plusieurs identifiants de rôle
level level Le niveau MLS/MCS
range range La plage que l'utilisateur peut utiliser.


user test_u roles staff_r level s0 range s0 - s15:c0.c1023;

^
08 mai 2017




mcstransd

mcstransd

Service MCS. Traduit les labels MCS/MLS sous forme lisible

OPTIONS

-F Ne lance pas en tâche de fond
^
07 mai 2017




rewrole

rewrole

Lancer un shell avec un nouveau rôle SELinux

   Le nouveau contexte est dérivé de l'ancien contexte dans lequel newrole est exécuté. Si un rôle est spécifié mais pas le domaine, le type par défaut est dérivé du rôle spécifié par le niveau.

OPTIONS

-r, --role ROLE Spécifie le nouveau contexte
-t, --type TYPE Spécifie le nouveau domaine
-l, --level Spécifie le niveau ou plage
-p, --preserve-environment Préserve les variables d'environnment, sinon un nouvel environnement minimal est créé

Exemples

Changer de rôle
› id -Z
staff_u:staff_r:staff_t:SystemLow-SystemHigh
› newrole -r sysadm_r
› id -Z
staff_u:sysadm_r:sysadm_t:SystemLow-SystemHigh
Changer la sensibilité
› id -Z
staff_u:sysadm_r:sysadm_t:Unclassified-SystemHigh
› newrole -l Secret
› id -Z
staff_u:sysadm_r:sysadm_t:Secret-SystemHigh
Changer la sensibilité
› id -Z
staff_u:sysadm_r:sysadm_t:Unclassified-SystemHigh
› newrole -l Secret-Secret
› id -Z
staff_u:sysadm_r:sysadm_t:Secret
Lancer un programme d-ans un contexte et niveau donné:
› newrole -r sysadm_r -- -c "/path/to/app arg1 arg2..."
› newrole -l Secret -- -c "/path/to/app arg1 arg2..."
^
07 mai 2017




/etc/selinux/newrole_pam.conf

/etc/selinux/newrole_pam.conf

Configuration pour newrole

   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

^
08 mai 2017




pam_sepermit

pam_sepermit

Module PAM pour autoriser/refuser le login en fonction de l'état d'enforcement SELinux

   Quand un utilisateur se log et match une entrée dans le fichier de configuration, il est autorisé seulement quand SELinux est en mode enforcing, sinon l'accès lui est refusé. Pour les utilisateurs qui ne matchent pas dans le fichier de configuration, le module retourne PAM_IGNORE.

OPTIONS

debug mode debug
conf=/path/to/conf/file Chemin alternatif du fichier de configuration

   Ce module fournis les type auth et account

Valeurs de retour

PAM_AUTH_ERR SELinux est désactivé ou en mode permissif et l'utilisateur match.
PAM_SUCCESS SELinux est en mode enforcing et l'utilisateur match
PAM_IGNORE L?utilisateur ne match pas
PAM_USER_UNKNOWN Le module n'est pas capable de déterminer le nom utilisateur
PAM_SERVICE_ERR Erreur durant la lectule du fichier de configuration

Exemple

auth [success=done ignore=ignore default=bad] pam_sepermit.so
auth required pam_unix.so
account required pam_unix.so
session required pam_permit.so
^
07 mai 2017




/usr/libexec/selinux/hll/pp

/usr/libexec/selinux/hll/pp

Lit un fichier .pp et affiche l'équivant CIL

   Si le fichier d'entrée n'est pas fournis, ou '-', lis depuis stdin. Si le fichier de sortie n'est pas spécifié, ou '-', affiche CIL sur stdout

^
05 mai 2017




/etc/selinux/<SELINUXTYPE>/contexts/removable_context

/etc/selinux/‹SELINUXTYPE›/contexts/removable_context

Fichier de configuration de contexte de périphériques débranchable

   Ce fichier contient le label par défaut qui devrait être utilisé pour les périphériques hot-plug qui ne sont pas définis dans le fichier media. Le fichier consiste d'une seule ligne user:role:type[:range]

Exemple

system_u:object_r:removable_t:s0
^
07 mai 2017




restorecon

restorecon

Restaure les contextes de sécurité par défaut SELinux

   Ce programme est principalement utilisé pour réinitialiser le contexte de sécurité d'un ou plusieurs fichiers. Il peut être lancé à tout moment pour corriger des erreurs, ajouter le support pour de nouvelles stratégies, ou avec l'option -n pour simplement vérifier les contextes. Si un objet fichier n'a pas de contexte, restorecon écrit un contexte par défauut dans les attributs étendus de l'objet fichier. Si nu objet fichier a un contexte, restorecon ne modifie que la portion de type du contexte de sécurité.

OPTIONS

-i ignore les fichiers qui n'existent pas
-f infilename Fichier contenant une liste de fichiers à traiter pal l'application, ou '-' pour stdin
-e directory Répertoire à exclure. Peut être spécifié plusieurs fois
-R, -r Change les labels des fichiers et répertoires récursivement
-n  Ne change par les labels
-o outfilename Sauve la liste des fichiers avec un context incorrect dans ce fichier
-P Affiche une progression en affichant un '*' tous les 1000 fichiers
-v Affiche les changements dans les labels
-F Force à réinitialiser le contexte pour correspondre à file_context pour les fichiers personnalisable, et le contexte de fichier par défaut, en changeant l'utilisateur, rôle, plage et le type.
^
07 mai 2017




restorecond

restorecond

Service qui supervise la création de fichier et définis le contexte de fichier SELinux par défaut

   Ce service utilise inotify pour voir les fichiers listés dans le fichier /etc/selinux/restorecond.conf. Quand ils sont créés, ce service s'assure que le contexte du fichier est correct en accord avec la stratégie

OPTIONS

-d mode debug
-f restorecond_file Spécifie un fichier de configuration alternatif
-u Active le mode utilisateur. ans restorecond dans la session utilisateur et lis /etc/selinux/restorecond_user.conf. Utilise Dbus pour s'assure que seul une instance restorecond tourne par session utilisateur.
-v mode verbeux
^
07 mai 2017




/etc/selinux/restorecond.conf

/etc/selinux/restorecond.conf, restorecond-user.conf

Configuration pour restorecond

   restorecond.conf contient une liste de fichiers qui peuvent être créé par les applications avec un contexte de sécurité incorrect. Le service restorecond vérifie leur création et corrige leur contexte de sécurité en accord avec les fichiers de configuration de stratégie active /etc/selinux/‹policy_name›/contexts/files. Chaque ligne du fichier contient le chemin complet d'un fichier ou répertoire. Les entrées qui commencent avec un tilde seront étendus aux fichiers dans les répertoires personnels des utilisateurs. Noter qu'il est possible de lancer restorecond dans une session utilisateur avec l'option -u, et nécessite un fichier /etc/selinux/restorecond-user.conf.

^
08 mai 2017




secolor.conf

secolor.conf

Fichier de configuration de couleur SELinux

Ce fichier contrôle la couleur associée aux composants de contexte associés au context raw passé par selinux_raw_context_to_color(3). Quand les informations lié au contexte sont affichées en couleur par une application compatible SELinux. Le fichier a le format suivant:
color color_name = #color_mask
[...]
    
[...]
context_component string    *    fg_color_name bg_color_name

color Le mot clé color
color_name nom de la couleur (ex: red)
color_mask Masque de couleur avec un # qui décris les couleurs RGB hexadécimal. black = #000000 et white = #ffffff
context_component Nom du composant de contexte (user, role, type ou range)
string change context_component qui matche le contexte raw. un '=' peut être utilisé pour matcher toute les types.
fg_color_name nom de couleur utilisé pour le texte
bg_color_name Nom de couleur utilisé pour le fond

Exemples

Exemple 1:
color black = #000000
color green = #008000
color yellow = #ffff00
color blue = #0000ff
color white = #ffffff
color red = #ff0000
color orange = #ffa500
color tan = #D2B48C
user * = black white
role * = white black
type * = tan orange
range s0-s0:c0.c1023 = black green
range s1-s1:c0.c1023 = white green
range s3-s3:c0.c1023 = black tan
range s5-s5:c0.c1023 = white blue
range s7-s7:c0.c1023 = black red
range s9-s9:c0.c1023 = black orange
range s15:c0.c1023 = black yellow
Exemple 2:
color black = #000000
color green = #008000
color yellow = #ffff00
color blue = #0000ff
color white = #ffffff
color red = #ff0000
color orange = #ffa500
color tan = #D2B48C
user unconfined_u = #ff0000 green
role unconfined_r = red #ffffff
type unconfined_t = red orange
user user_u = black green
role user_r = white black
type user_t = tan red
user xguest_u = black yellow
role xguest_r = black red
type xguest_t = black green
user sysadm_u = white black
range s0:c0.c1023 = black white
user * = black white
role * = black white
type * = black white
^
05 mai 2017




/etc/selinux/<SELINUXTYPE>/contexts/securetty_types

/etc/selinux/‹SELINUXTYPE›/contexts/securetty_types

Fichier de configuration de type tty sécurisé SELinux

   Ce fichier contient une liste de types associés aux type tty qui est définis dans la stratégie utilisée par les application. Chaque ligne dans ce fichier contient un type définis dans la stratégie pour les périphériques tty sécurisés

Exemple

sysadm_tty_device_t
user_tty_device_t
staff_tty_device_t
^
07 mai 2017




/etc/selinux/<SELINUXTYPE>/contexts/sepgsql_context

/etc/selinux/‹SELINUXTYPE›/contexts/sepgsql_context

Fichier de configuration et labeling SELinux pour les objects RDBMS

   Le format est object_type object_name context

object_type Est la représentation du type d'objet:

        db_database object_name spécifie le nom d'une base de données
        db_schema object_name spécifie le nom d'un objet schéma
        db_table object_name spécifie le nom d'une table
        db_column object_name spécifie le nom d'une colonne
        db_tuple object_name spécifie le nom d'une table qui contient les tuples à relabéliser
        db_procedure object_name spécifie le nom d'une procédure
        db_sequence object_name spécifie le nom d'une séquence
        db_blob object_name spécifie le nom d'un grand objet. Noter qu'un grand objet n'a pas de nm, il est identifié par sa valeur identifiant
        db_view object_name spécifie le nom d'une vue
        db_language object_name spécifie le nom d'un langage
        db_exception object_name spécifie le nom d'une exception
        db_datatype object_name spécifie le nom d'un type ou domaine

Exemples


db_database my_database system_u:object_r:sepgsql_db_t:s0
db_database *     system_u:object_r:sepgsql_db_t:s0
db_schema generator.php system_u:object_r:sepgsql_schema_t:s0
db_tuple row_low system_u:object_r:sepgsql_table_t:s0
db_tuple row_high system_u:object_r:sepgsql_table_t:s0:c1023
db_tuple *.*.* system_u:object_r:sepgsql_table_t:s0
^
07 mai 2017




/etc/selinux/<SELINUXTYPE>/contexts/files/file_contexts

/etc/selinux/‹SELINUXTYPE›/contexts/files/file_contexts, file_contexts.local, file_contexts.homedirs, file_contexts.subs, file_contexts.subs_dist

Fichier de configuration et labeling SELinux pour les backend de contexte de fichier

   Le backend de contextes de fichier mappe depuis les combinaisons pathname/mode en contextes de securité. C'est utilisé pour trouver le contexte approprié pour chaque fichier en relabélisant un système de fichier. Le format est pathname [file_type] context. Les fichiers de substitution (.subs, et .subs_dist) ont le format subs_pathname pathname

pathname Une entrée qui définis le chemin qui peut être sous la forme d'une expression régulière. Pour les fichiers de substitution, matche un ou plusieurs fichier de configuration de stratégie de contexte de fichier
file_type type de fichier: -b, -c, -d, -p, -d, -l, -s, --.
subs_pathname Le chemin qui est considéré comme équivalent avec pathname par le processus de recherche.

Exemple

Exemple de fichier file_contexts
/. /.. system_u:object_r:default_t:s0
/[^/]+ -- system_u:object_r:etc_runtime_t:s0
/tmp/.* ‹‹none››

Exemple de fichier file_contexts.subs
/myweb /var/www
/myspool /var/spool/mail
^
07 mai 2017




/etc/selinux/<SELINUXTYPE>/contexts/files/media

/etc/selinux/‹SELINUXTYPE›/contexts/files/media

Fichier de configuration pour le backend de contexte de média

   Le backend de contextes de média mappe les noms de périphériques tel que 'cdrom' ou 'floppy' en contextes de sécurité. Il est utilisé pour trouver le contexte approprié puor établir les contextes au montage de ces périphériques. Le format de ce fichier est device_name context

device_name l'identifiant de média, par ex. cdrom, floppy, disk et usb

Exemple


cdrom system_u:object_r:removable_device_t
floppy system_u:object_r:removable_device_t
disk system_u:object_r:fixed_disk_device_t
^
07 mai 2017




/etc/selinux/<SELINUXTYPE>/contexts/x_context

/etc/selinux/‹SELINUXTYPE›/contexts/x_context

Fichier de configuration et labeling SELinux pour les objects X Window System

   Le backend de contexte X mappe les noms d'objets X en contextes de sécurité. Il est utilisé pour trouver le contexte approprié pour les objets X Window System dont la signification et/ou l'utilisation sont déterminés par nom. Le format est object_type object_name context

object_type Est la représentation du type d'objet:

        property object_name spécifie le nom d'une propriété de fenêtre, tel que "WM_NAME"
        selection object_name spécifie le nom d'une sélection, tel que "PRIMARY"
        extension object_name spécifie le nom d'une extension de protocole, tel que "RENDER"
        event object_name spécifie le nom d'un type d'évènement, tel que "X11:ButtonPress"
        client object_name est ignoré, cependant il devrait être mis à soit '*', ou une entrée spécifique tel que "remote".
        poly_property idem à property, mais vérifie que la propriété est marguée comme polyinstanciée.
        poly_selection idem à selection, mais vérifie que la sélection est marquée comme polyinstanciiée.

Exemple


selection PRIMARY system_u:object_r:clipboard_xselection_t:s0
selection *     system_u:object_r:xselection_t:s0
client *     system_u:object_r:remote_t:s0
^
07 mai 2017




/etc/selinux/config

/etc/selinux/config



   Ce fichier contrôle l'état de SELinux:

        1. Le status d'application de la stratégie
        2. Le nom de la stratégie et le type qui forment un chemin vers la stratégie à charger
        3. Le comportement au regard des utilisateurs quand la stratégie est chargée
        4. Comment les applications login compatibles SELinux doivent se comporter si aucun utilisateur SELinux n'est configuré
        5. Si le système doit être relabélisé ou non.

OPTIONS

SELINUX Cette entrée indique l'application de la stratégie: enforcing, permissive, ou disabled
SELINUXTYPE Identifie le type de stratégie et doit être le nom d'un répertoir e sous /etc/selinux.
REQUIREUSERS (bool) Permet d'échouer un login s'il n'y a pas de match en d'entrée par défaut dans le fichier seusers
AUTORELABEL (bool) à 0, s'il existe un fichier .autorelabel dans le répertoire racine, alors le loader donne un shell où root peut manuellement relabéliser le système de fichier. À 1 et un fichier .autorelabel, le système relabélise automatiquement en utilisant fixfiles -F restore
^
04 mai 2017




semanage

semanage

Outil de gestion de stratégie SELinux

   semanage est utilisé pour configurer certains éléments de la stratégie SELinux sant nécessiter de modification ou recompilation. Cela inclus le mappage des usernames linux en user SELinux et les mappages de contexte de sécurité pour divers types d'objet. semanage possède les sous-commandes suivantes:

import Importer des personnalisations locales
export Exporte des personnalisations locales
login Gérer les mappages entre les users Linux et SELinux
port Gérer les définitions de type de port réseau
interface Gérer les définitions de type d'interface réseau
module Gérer les modules de stratégie SELinux
node Gérer les définitions de type de nœud réseau
fcontext Gérer les définitions de mappage de contexte de fichier
boolean Gérer les booléens pour activer des fonctionnalités
permissive Gérer le mode d'enforcement
dontaudit Active/désactive les rèoles dontaudit dans la stratégie

^
04 mai 2017




semanage-boolean

semanage-boolean

Gestion des booléen SELinux

   semanage boolean contrôle les paramètres booléens dans la stratégie SELinux.

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-C, --locallist Lister les personnalisations locales
-S STORE, --store STORE Magasin alternatif
-m, --modify Modifie un enregistrement du type d'objet spécifié
-l, --list Liste les enregistrement du type d'objet spécifié
-E, --extract Extrait les commandes personnalisables, à utiliser dans une transaction
-D, --deleteall Supprimer toutes les personnalisation locales
-1, --on active le booléen
-0, --off Désactive le booléen

Exemples

Active le booléen apache peut envoyer un mail
semanage boolean -m --on httpd_can_sendmail
lister les booléens personnalisés
semanage boolean -l -C
^
04 mai 2017




semanage-dontaudit

semanage-dontaudit

Gestion dontaudit

   semanage dontaudit active/désactive les règles dontaudit dans la stratégie. Désactiver les règles dontaudit permet de vois si le kernel bloque un accès

OPTIONS

-N, --noreload Ne par recharger la stratégie après le commit
-S STORE, --store STORE Magasin alternatif

Exemples

Désactiver les règles dontaudit:
semanage dontaudit off
^
04 mai 2017




semanage-export

semanage-export

Exporter des modifications SELinux

   semanage import et export peuvent être utilisés pour extraire les modifications SELinux d'une machine et les appliquer sur une autre.

OPTIONS

-S STORE, --store STORE Magasin alternatif
-f OUTPUT_FILE, --output_file OUTPUT_FILE Fichier de sortie

Exemples

Appliquer les modification à une autre machine:
semanage export -f semanage.mods
scp semanag.mod remodemachine:
ssh remodemachine
semange -import -f semanage.mods
^
04 mai 2017




semanage-fcontext

semanage-fcontext

Gestion des contextes de fichier

   semanage fcontext est utilisé pour gérer les labels de système de fichier par défaut dans un système SELinux. Cette commande mappe les chemins de fichier en utilisant des expressions régulières en labels SELinux

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-C, --locallist Lister les personnalisations locales
-S STORE, --store STORE Magasin alternatif
-a, --add Ajoute un enregistrement du type d'objet spécifié
-d, --delete Supprime un enregistrement du type d'objet spécifié
-m, --modify Modifie un enregistrement du type d'objet spécifié
-l, --list Liste les enregistrement du type d'objet spécifié
-E, --extract Extrait les commandes personnalisables, à utiliser dans une transaction
-D, --deleteall Supprimer toutes les personnalisation locales
-e EQUAL, --equal EQUAL Substitue le chemin cible avec le sourcepath en générant le label par défaut.
-f [{a,f,d,c,b,s,l,p}], --ftype [{a,f,d,c,b,s,l,p}] Type de fichier.
-s SEUSER, --seuser SEUSER Nom de l'utilisateur SELinux
-t TYPE, --type TYPE Type SELinux pour l'objet
-r RANGE, --range RANGE plage MLS/MCS

Exemples

Ajoute un contexte de fichie pour tous les fichiers sous /web
semanage fcontext -a -t httpd_sys_content_t "/web[/.*)?"
restorecon -R -v /web
Substituer /home1 avec /home en définissant le contexte de fichier
semanage fcontext -a -e /home /home1
restorecon -R -v /home1
Pour les répertoires personnels sou le répertoire racine (ex: /disk6/home), exécuter les commandes suivantes:
semanage fcontext -a -t home_root_t "/disk6"
semanage fcontext -a -e /home /disk6/home
restorecon -R -v /disk6
^
04 mai 2017




semanage-import

semanage-import

Importer des modifications SELinux

   semanage import et export peuvent être utilisés pour extraire les modifications SELinux d'une machine et les appliquer sur une autre.

OPTIONS

-N, --noreload Ne par recharger la stratégie après le commit
-S STORE, --store STORE Magasin alternatif
-f INPUT_FILE, --input_file INPUT_FILE Fichier d'entrée
^
04 mai 2017




semanage-interface

semanage-interface

Outil de gestion d'interface réseaux

   semanage interface contrôle les labels assignés aux interfaces réseaux

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-C, --locallist Lister les personnalisations locales
-S STORE, --store STORE Magasin alternatif
-a, --add Ajoute un enregistrement du type d'objet spécifié
-d, --delete Supprime un enregistrement du type d'objet spécifié
-m, --modify Modifie un enregistrement du type d'objet spécifié
-l, --list Liste les enregistrement du type d'objet spécifié
-E, --extract Extrait les commandes personnalisables, à utiliser dans une transaction
-D, --deleteall Supprimer toutes les personnalisation locales
-t TYPE, --type TYPE Type SELinux pour l'objet
-r RANGE, --range RANGE plage MLS/MCS
^
04 mai 2017




semanage-login

semanage-login

Gestion des mappages des utilisateurs Linux et SELinux

   semanage login contrôle le mappage entre un utilisateur Linux et un utilisateur SELinux. Il peut être utilisé pour activer des utilisateurs confinés. Par exemple on peurrait définis qu'un utilisateur particulier ou un groupe d'utilisateurs vont se logger dans un système en tant que user_u. Préfixer un nom de groupe avec '%'.

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-C, --locallist Lister les personnalisations locales
-S STORE, --store STORE Magasin alternatif
-a, --add Ajoute un enregistrement du type d'objet spécifié
-d, --delete Supprime un enregistrement du type d'objet spécifié
-m, --modify Modifie un enregistrement du type d'objet spécifié
-l, --list Liste les enregistrement du type d'objet spécifié
-E, --extract Extrait les commandes personnalisables, à utiliser dans une transaction
-s SEUSER, --seuser SEUSER Nom d'utilisateur SELinux
-r RANGE, --range RANGE plage MLS/MCS

Exemples

Modifier l'utilisateur default dans le système en guest_u
semanage login -m -s guest_u __default__
assigner à l'utilisateur gijoe dans une machine MLS une plage et l'utilisateur staff_u
semanage login -a -s staff_u -rSystemLow-Secret gijoe
assigner tous les utilisateurs du groupe engineering à l'utilisateur staff_u
semanage login -a -s staff_u %engineering
^
04 mai 2017




semanage-module

semanage-module

Installe, supprime et désactive les modules de stratégie SELinux

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-C, --locallist Lister les personnalisations locales
-S STORE, --store STORE Magasin alternatif
-a, --add Ajoute un enregistrement du type d'objet spécifié
-r, --remove Supprime le module spécifié
-d, --disable Désactive le module spécifié
-e, --enable Active le module spécifié
-l, --list Liste les enregistrement du type d'objet spécifié
-E, --extract Extrait les commandes personnalisables, à utiliser dans une transaction
^
04 mai 2017




semanage-node

semanage-node

Contrôle les adresses IP en définition de type de nœud

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-C, --locallist Lister les personnalisations locales
-S STORE, --store STORE Magasin alternatif
-a, --add Ajoute un enregistrement du type d'objet spécifié
-d, --delete Supprime un enregistrement du type d'objet spécifié
-m, --modify Modifie un enregistrement du type d'objet spécifié
-l, --list Liste les enregistrement du type d'objet spécifié
-E, --extract Extrait les commandes personnalisables, à utiliser dans une transaction
-D, --deleteall Supprimer toutes les personnalisation locales
-t TYPE, --type TYPE Type SELinux pour l'objet
-r RANGE, --range RANGE plage MLS/MCS
-p PROTO, --proto PROTO Protocole pour le port spécifié (tcp|udp) ou version du protocole internet pour le nœud spécifié (ipv4|ipv6)
-M NETMASK, --netmask NETMASK Masque de sous-réseau
^
04 mai 2017




semanage-permissive

semanage-permissive

Gestion des mappages permissifs

   semanage permissive ajoute ou supprime un module permissif de stratégie SELinux

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-S STORE, --store STORE Magasin alternatif
-a, --add Ajoute un enregistrement du type d'objet spécifié
-d, --delete Supprime un enregistrement du type d'objet spécifié
-l, --list Liste les enregistrement du type d'objet spécifié

Exemples

Lister tous les modules permissifs
semanage permissive -l
faire de httpd_t un domaine permissif
semanage permissive -a httpd_t
^
04 mai 2017




semanage-port

semanage-port

Outil de gestion de mappage de port

   semanage port contrôle le numéro de port en définitions de type de port

OPTIONS

-n, --noheading Ne pas afficher les en-tête dans le listing des type d'objet
-N, --noreload Ne par recharger la stratégie après le commit
-C, --locallist Lister les personnalisations locales
-S STORE, --store STORE Magasin alternatif
-a, --add Ajoute un enregistrement du type d'objet spécifié
-d, --delete Supprime un enregistrement du type d'objet spécifié
-m, --modify Modifie un enregistrement du type d'objet spécifié
-l, --list Liste les enregistrement du type d'objet spécifié
-E, --extract Extrait les commandes personnalisables, à utiliser dans une transaction
-D, --deleteall Supprimer toutes les personnalisation locales
-t TYPE, --type TYPE Type SELinux pour l'objet
-r RANGE, --range RANGE plage MLS/MCS
-p PROTO, --proto PROTO Protocole pour le port spécifié (tcp|udp) ou version du protocole internet pour le nœud spécifié (ipv4|ipv6)

Exemples

Lister toutes les définitions de port
semanage port -l
autoriser Apache à écouter sur tcp port 81
semanage port -a -t http_port_t -p tcp 81
autoriser sshd à écouter sur le port tcp 8991
semanage port -a -t ssh_port_t -p tcp 8991
^
04 mai 2017




semanage.conf

semanage.conf

Fichier de configuration global pour la libraire de gestion SELinux

OPTIONS

module-store Spécifie comment la libraire interagit avec le magasin de stratégie SELinux

        direct Écris directement dans le magasin de stratégie (défaut)
        ‹socket path› Chemin absolu vers un socket utilisé pour se connecter au serveur de gestion de stratégie
        ‹server name› Nom et port d'un serveur de gestion de stratégie utilisé sur TCP.

root Chemin racine alternatif pour le magasin. Défaut: /
store-root Chemin racine du magasin alternatif. Défaut: /var/lib/selinux
compiler-directory Répertoire alternatif contenant les compilateurs HLL vers CIL. Défaut: /usr/libexec/selinux/hll
ignore-module-cache true|false ignore ou non le cache des modules CIL compilés depuis HLL. Défaut: false.
policy-version en générant la stratégie, semanage défini POLICYDB_VERSION_MAX tel que définis dans ‹sepol/policydb/policydb.h›. Ce paramètre permet de définir une autre versions
target-platform 0|1 Vérifie ou non les règles neverallow en exécutant la commande semanage. Défaut: 1
file-mode Par défaut le mode de permission pour les fichiers de stratégie temps-réer est à 0644
save-previous true|false Contrôle si le répertoire du module précédent est sauvé après être validé avec succès dans le magasin de stratégie. Défaut: false (la version précédente est supprimée)
save-linked true|false Contrôle si le module lié précédent est sauvé (avec le nom base.linked) une fois correctement chargé dans le magasin de stratégie. Défaut: false (le module précédent est supprimé)
ignoredirs Liste de répertoires séparés par des ';' de répertoires à ignorer en définisant les répertoires personnels utilisateur.
usepasswd true|false Active l'utilisation de getpwent() pour obtenir une liste de répertoire home à labéliser. défaut: true
disable-genhomedircon true|false Contrôle si la fonction genhomedircon est exécutée avec la commande semanage. Défaut: false
handle-unknown deny|reject|allow Contrôle le comportement du kernel pour gérer les permisssions définies dans le kernel, mais manquante dans la stratégie courante.
bzip-blocksize [0-9] 0-pas de compression. Défaut: 9
bzip-small true|false indique si l'algorithme bzip tente de réduire son utilisation mémoire. Défaut: false
remove-hll true|false à true, les fichiers HLL seront supprimés après recompilation dans CIL.
^
07 mai 2017




semodule

semodule

Gérer les modules de stratégie SELinux

   semodule est l'outil utilisé pour gérer les modules de stratégie SELinux, incluant l'installation, la mise à jours, le listing et la suppression des modules. semodule peut également être utilisé pour reconstruire une stratégie depuis un magasin de module et/ou forcer à recharger une stratégie sans effectuer d'autre transactions. semodule agit sur les paquets de module créés par semodule_package. Par convention, ces fichiers ont un suffixe .pp (policy package).

OPTIONS

-R, --reload Force à recharger une stratégie
-B, --build Force à reconstruire une stratégie (recharge également sauf si -n)
-D, --disable_dontaudit Supprime temporairement dontaudits de la stratégie
-i, --install=MODULE_PKG Install/remplace un paquet module
-r, --remove=MODULE_NAME Supprime un module existant
-l[KIND], --liste-modules[=KIND] Affiche une liste des modules installés
-E, --extract=MODULE_PKG Extrait un module du magasin comme fichier HLL ou CIL dans le répertoire courant.

KIND

        standard Liste la plus haut priorité
        full Liste tous les modules

-X,--priority=PRIORITY Définis la priorité pour les opérations qui suivent (1-999)
-e, --enabled=MODULE_NAME Active un module
-d, --disable=MODULE_NAME désactive un module
-s, --store Nom du magasin à utiliser pour les opérations
-n, --noreload, -N ne pas recharger la stratégie
-p, --preserve_tunables préserve tunables in policy
-C, --ignore-module-cache Recompile les module CIL construis depuis les fichiers HLL
-p, --path Chemin alternatif pour la racine de stratégie
-S, --store-path Chemin alternatif pour la racine du magasin de stratégie
-v, --verbose mode verbeux
-c, --cil Extrait le module comme fichier CIL
-H, --hll Extrait le module comme fichier HLL

Exemples

Installer ou remplacer un paquet de stratégie de base
semodule -b base.pp
installer ou remplacer un paquet de stratégie non base
semodule -i httpd.pp
Lister les module non de base
semodule -l
Activer tous les messages AVC pour lesquels SELinux est actuellement en 'dontaudit'
semodule -DB
Réapplique les règles 'dontaudit'
semodule -B
Installer ou remplacer tous les modules non-base dans le répertoire courant
semodule -i *.pp
Installer ou remplacer tous les modules dans le répertoire courant
ls *.pp | grep -Ev "base.pp|enableaudit.pp" | xargs /usr/sbin/semodule -b base.pp -i
Désactiver un module
semodule -d alsa
Installer un module avec une priorité spcifique
semodule -X 100 -i alsa.pp
Lister tous les modules
semodule --list=full
Définir un chemin alternatif pour la racine des stratégie
semodule -B -p "/tmp"
Écris la version HLL de puppet et la version CIL de wireshark
semodule -X 400 -E puppet --cil -E wireshark
^
08 mai 2017




/etc/security/sepermit.conf

/etc/security/sepermit.conf

fichier de configuration pour pam_sepermit

   Les lignes sont sous la forme ‹user›[:‹option›:‹option›...]. Un utilisateur peut être un username, un @group, ou un utilisateur SELinux (%seuser)

OPTIONS

exclusive Seul une session login est permise pour l'utilisateur et les processus de l'utilisateur seront tués au logout
ignore Le module ne retourne jamais PAM_SUCCESS pour l'utilisateur. Il retourne PAM_IGNORE si SELinux est en mode enforcing, PAM_AUTH_ERR sinon. Utile pour supporter les utilisateurs invités sans mot de passe et des utilisateurs confinés sans mot de passe simultanément.
^
07 mai 2017




service_seusers

service_seusers

Fichiers de configuration de mappage d'utilisateur et service en utilisateur SELinux

   Ces fichiers sont optionnels et permettent aux services de définir un utilisateur SELinux à l'authentification. Il y a un fichier pour chaque utilisateur GNU/Linux qui est requis pour lancer un service avec un username SELinux spécifique. Chaque ligne a le format service:seuser[:range]

service Le nom du service utilisé par l'application
seuser Le nom d'utilisateur SELinux
range La plage MCS/MLS

Exemple


# ./logins/root
ipa:user_u:s0
this_service:unconfined_u:s0
    
# ./logins/rch
ipa:unconfined_u:s0
that_service:unconfined_u:s0
^
07 mai 2017




sestatus

sestatus

Outils de status SELinux

   sestatus est utilisé pour obtenir le status d'un système avec SELinux

OPTIONS

-v Affiche les fichiers de contexte des fichiers et processus listés dans /etc/sestatus.conf
-b Affiche l'état courant des booléens
^
07 mai 2017




/etc/sestatus.conf

/etc/sestatus.conf

Fichier de configuration pour sestatus

   sestatus -v utilise ce fichier pour déterminer quel contexte de sécurité de fichier et processus devraient être affichés. Le fichier consiste de 2 sections optionnelles [files] et [process].

[files] Début d'une liste de fichier
file_name Un ou plusieurs noms de fichiers complet, chacun sur une ligne, dont le contexte sera affiché. Si le fichier n'existe pas il est ignoré. Si c'est un lien symbolique, affihe le contexte de la cible
[process] Début d'une liste de processus
executable_file_name Un ou plusieurs fichiers exécutable complet qui devraient être dans un processus actif, et dont le contexte sera affiché.

Exemples


[files]
/etc/passwd
/etc/shadow
/bin/bash
/bin/login
/lib/libc.so.6
/lib/ld-linux.so.2
/lib/ld.so.1
    
[process]
/sbin/mingetty
/sbin/agetty
/usr/sbin/sshd
^
08 mai 2017




/etc/selinux/<SELINUXTYPE>/setrans.conf

/etc/selinux/‹SELINUXTYPE›/setrans.conf

Fichier de configuration de traduction pour les systèmes SELinux MCS/MLS

   Ce fichier spécifie la manière dont les labels MCS/MLS sont traduits sous forme lisible par l'homme par les service mcstransd. Les stratégies par défaut ne supportent que 16 niveaux de sensibilité (s0 à s15) et 1024 catégories (c0 à c1023). Plusieurs catégories peuvent être séparés par des ',' et une plage de catégorie peut être raccourcie en utilisant un '.'

Mots clés

Base Une fois une base déclarée, les définitions de label suivant possèderont tous ces modificateurs durant la traduction.
Default Définit le bit de plage de catégorie utilisé pour les bits inverses
Domain Créé un nouveau domaine avec le nom fournis
Include Lit et traite le contenu du fichier de configuration spécifié
Join Définis un caractère utilisé pour séparer les membres d'un ModifierGroup
ModifierGroup Un moyen de grouper des définitions de bit de catégorie par la manière dont ils modifient le label de sensibilité
Prefix Mot(s) préfixe qui peuvent précéder les membres d'un modifiergroup
Suffix Mot(s) suffixe qui peuvent suivre les membres d'un modifiergroup
Whitespace Définis le jeu de caractère d'espace blanc acceptables qui peuvent être utilisé dans les labels traduits

Exemples de définition de niveau de sensibilité
s0=SystemLow
Définis une traduction de s0 (le niveau de sensibilité la plus faible) sans catégorie.
s15:c0.c1023=SystemHigh
Définis une traduction de s15:c0.c1023 en system SystemHigh. c0.c1023 est un raccourcis pour toutes les catégories.
s0-s15:c0.c1023=SystemLow-SystemHigh
Définis une traduction de s0-s15:c0.c1023 en SystemLow-SystemHigh.
s0:c0=PatientRecord
Définis une traduction de la sensibilité s0 avec la catégorie c0 en PatientRecord
s0:c1*Accounting
Définis une traduction de la sensibilité s0 avec la catégorie c1 en Accounting
s2:c1,c2,c3=Confidential3Categories
s2:c1.c3=Confidential3Categories
Définissent une traduction de la sensibilité s2 avec les catégories c1, c2 et c3 en Confidential3Categories
s5=TopSecret
Définis une traduction de la sensibilité s5 sans catégorie en TopSecret

Exemples de contraintes
c0!c1 Si les bits de catégorie 0 et 1 sont mis, la contrainte échoue et le contexte original est retourné
c5.c9›c1
Si les bits 5 à 9 sont mis et le niveau de sensibilité s1, la contrainte échoue
s1!c5,c9
Si les bits 5 et 9 sont mis et le niveau de sensibilité est s1, la contrainte échoue.
^
08 mai 2017




/etc/selinux/<SELINUXTYPE>/seusers

/etc/selinux/‹SELINUXTYPE›/seusers

Fichier de configuration de mappage des utilisateurs GNU/Linux en utilisateurs SELinux

   Ce fichier est utilisé par les application de connexions compatible SELinux. selinux_usersconf_path(3) retourne le chemin de la stratégie active vers ce fichier. getseuserbuname(3) lit ce fichier pour maper un utilisateur ou groupe en un utilisateur SELinux. Chaque ligne consiste des champs suivants [%group_id]|[user_id]:seuser_id[:range]

group_id|user_id Le GID/UID GNU/Linux. une entrée __default__ peut être fournis.
seuser_id L'identité utilisateur SELinux
range Niveau ou plage optionnelle pour une stratégie MLS/MCS

Exemple


__default__:user_u:s0
system_u:system_u:s0-s15:c0.c255
root:root:s0-s15:c0.c255
fred:user_u:s0
%user_group:user_u:s0
^
07 mai 2017




/etc/selinux/<SELINUXTYPE>/contexts/users/<se_user>

/etc/selinux/‹SELINUXTYPE›/contexts/users/‹se_user›

Fichiers contenant les entrées qui permettent de déterminer le contexte d'un utilisateur à l'ouverture d'une session

   Il y a un fichier pour chaque utilisateur SELinux configuré dans le système. Chaque ligne dans le fichier de configuration a le format login_process user_login_process

login_process consiste d'une entrée role:type[:range] qui représente le contexte du processus de login
user_login_process consiste d'une entrée role:type[:range] qui représente le contexte du processus de login de l'utilisateur

Exemple


system_r:crond_t:s0 xguest_r:xguest_t:s0
system_r:initrc_t:s0 xguest_r:xguest_t:s0
system_r:local_login_t:s0 xguest_r:xguest_t:s0
system_r:remote_login_t:s0 xguest_r:xguest_t:s0
system_r:sshd_t:s0 xguest_r:xguest_t:s0
system_r:xdm_t:s0 xguest_r:xguest_t:s0
xguest_r:xguest_t:s0 xguest_r:xguest_t:s0
^
24 mars 2017




ANSI-INCITS_359-2004

ANSI-INCITS_359-2004

Le modèle de contrôle d'accès basé sur des rôles

Scope

   Ce standard consiste de 2 parties - le modèle de référence RBAC, et la spécification fonctionnelle système et administrative de RBAC.

   Le modèle de référence RBAC définis un jeu d'éléments de base RBAC (par exemple, des utilisateurs, des rôles, des permissions, opérations et objets) et les relations comme les types et fonctions qui sont incluses dans ce standard. Le modèle de référence RBAC sert 2 buts. D'abord, il référence le périmètre des fonctionnalités RBAC qui sont incluses dans le standard. Il identifie le jeu minimum de fonctionnalités inclus dans tous les système RBAC, les aspects de la hiérarchie de rôle, de relations de contraintes statiques, et de relations de contraintes dynamiques. Ensuite, le modèle de référence fournis un langage précis et consistant, en termes de jeux d'éléments et de fonctions à utiliser pour la définition de spécification fonctionnelles.

   Le système RBAC et la spécification fonctionnelle système et administrative RBAC spécifient les fonctionnalités qui sont requises d'un système RBAC. Ces fonctionnalités remplissent 3 catégories, les opérations administratives, les revues administratives, et la fonctionnalité de niveau système. Les opérations administratives définissent les fonctions en terme d'interface administrative et un jeu associé de sémantiques qui fournissent la capacité de créer, supprime et maintenir des éléments RBAC et des relations (ex, pour créer et supprimer des assignements de rôle utilisateur). Les fonctionnalités de revue administratives définissent des fonction en terme d'interface administratives et un jeu associé de sémantiques qui fournissent la capacité d'effectuer des opérations de requêtes sur des éléments et des relations RBAC. La fonctionnalité niveau système définie les fonctionnalité pour la création de sessions utilisateurs pour inclure l'activation/désactivation de rôles, les contraintes forcées dans l'activation de rôle, et pour le calcul d'une décision d'accès.

Conformité

   Toutes les fonctionnalités RBAC ne sont pas appropriées pour toutes les applications. Ce standard fournis une méthode de packaging de fonctionnalité via la sélection de composants fonctionnels et optionnels dans un composant, commençant avec un jeu cœur des fonctionnalité RBAC qui doivent être inclus dans tous les packages.

Conformité

   Pour ce conformer à ce standard, un système RBAC doit être conforme avec tout le jeu core des spécification fonctionnelles RBAC dans la clause 6.1. La conformité d'un système RBAC à d'autres spécification fonctionnelles pour un composant particulier et options, trouvés dans les clauses 6.2 à 6.4, est optionnel et dépendent des exigences fonctionnelles d'une application particulière.

Termes et définitions

Composant réfère à un des blocks majeurs des fonctionnalités RBAC.
Objets Peut être une ressource système sujet à contrôle d'accès, tel qu'un fichier, une imprimante, etc.
Opérations image exécutable d'un programme, qui à l'invocation exécute une fonction pour l'utilisateur.
Permissions Approbation pour effectuer une opération dans un ou plusieurs objets Protégés par RBAC.
role job d'un humain. bien que le concept d'utilisateur peut être étendus pour inclure des machines, réseaux, etc., la définition est limitée à une personne dans ce document.

Le modèle de référence RBAC

   Il est définis en terme de 4 composants: le cœur RBAC, La hiérarchie RBAC, séparation statique des privilèges, et séparation dynamique des privilèges. Le cœur RBAC définis une collection minimum d'éléments RBAC, de jeux d'éléments, et des relations pour achever le système RBAC. Cela inclus l'assignement de rôle utilisateur et les relations d'assignement permission/rôle, considérés comme fondammental dans un système RBAC. De plus, le cœur RBAC introduit le concept d'activation de rôle comme faisant partie d'une session utilisateur. Le cœur RBAC est requis dans tout système RBAC, mais les autres composants sont indépendants des autres et peuvent être implémentés séparémments.

   La hiérarchie RBAC ajoute les relations pour supporter les hiérarchies de rôle. Une hiérarchie est mathématiquement un ordre partiel définissant une relation d'apparentée entre les rôles, où les rôles séniors acquièrent les permissions de leurs juniors et les rôles juniors acquièrent les utilisateurs de leurs sénior. De plus, la hiérarchie RBAC va au-delà du simple assignement utilisateur et permission en introduisant le concept de jeu de rôles d'utilisateurs autorisé et de permissions autorisées. La séparation statique des relations de privilège ajoute des relations exclusives avec les rôles en respect des assignements utilisateur. À cause de potentiels inconsistances d'un hiérarchie de rôle, le modèle de relation SSD définis les relations sur la présence et l'absence des hiérarchies de rôle. La séparation dynamique des relations de privilèges définis les relations exclusives en respect des rôles qui sont activés, faisant partie de la session utilisateur.

   Chaque composant est définis par les sous-composants suivants:

- Un jeu de jeux d'éléments de base
- Un jeu de relations RBAC impliquant ces éléments (contenant des sous-jeu de produits cartésiens dénotant une assignement valide)
- Un jeu de fonction de mappage, qui maintiennent des instances de membre d'un éléments, définis pour une instance donnée depuis un autre jeu d'élément.

   Il est important de notser que le modèle de référence RBAC définis une taxonomie des fonctionnalités RBAC qui peuvent être composés en un nombre de package de foncionnalités. Au lieu de tenter de définir un jeu complet de fonctionnalité RBAC, ce modèle de concentre à produire un jeu standard de termes pour définir les foncitonnalités les plus saillantes comme représenté dans les modèles existants et implémenté dans les produits commerciaux.

cœur RBAC

   Le cœur RBAC inclus les jeux de 5 éléments de données de base appelés des utilisateurs (USERS), des rôles (ROLES), des objets (OBS), des opérations (OPS), et des permissions (PRMS). Le modèle RBAC dans son ensemble est fondamentalement définis en terme d'utilisateurs individuels étant assignés aux rôles et de permissions étant assignés aux rôles. Ainsi, un rôle est un moyen de nommer des relations many-to-many entre des individus et des permissions. De plus, le modèle du cœur RBAC inclus un jeu de sessions (SESSIONS) où chaque session est un mappage entre un utilisateur et un sous-jeu activé de rôle qui sont assignés à l'utilisateur.

   Un utilisateur est définis comme une personne. Bien que le concept d'un utilisateur peut être étendus pour inclure des machines, réseaux, ou des agents autonomes intelligents, la définition est limitée à une personne dans ce document pour des raisons de simplicité. Un rôle est une fonction (job) dans le contexte de l'organisation avec des sémantiques associées avec l'autorité et la responsabilité conférée à l'utilisateur assigné au rôle. Les permissions sont une approbation pour effectuer une opération sur un ou plusieurs objets protégés par RBAC. Une opération est une image exécutable d'une programme, qui à l'invocation exécute certaines fonctions pour l'utilisateur. Les types d'opérations et objets que RBAC contrôle sont dépendant du type de systèmes dans lequel il est implémenté. Par exemple, dans un système de fichier, les opérations peuvent inclure lire, écrire, et exécuter; dans une base de données, les opérations peuvent inclure insert, delete, append, et update.

   Le but de tout mécanisme de contrôle d'accès est de protéger les ressources système. Consistant avec les anciens modèles de contrôle d'accès un objet est une entité qui contient ou reçois des informations. Pour un système qui implémente RBAC, les objets peuvent représenter des conteneurs d'informations (par exemple des fichiers, répertoires, un système d'exploitation, colonnes/lignes/tables/views dans une base de données), ou des objets qui représentent des ressources systèmes exhaustives, tels qu'une imprimante, espace disque, et cycles CPU. Le jeu d'objets couvert par RBAC inclus tous les objets listés dans les permissions qui sont assignés aux rôles.

   Le centre de RBAC est le concept de relation de rôle, autour duquel un rôle est une construction sémantique pour formuler des stratégies. La figure ci-dessous illustre les relations d''assignement utilisateur (UA) et d'assignement de permission (PA). Les flèches indiquent une relation many-to-many (ex: un utilisateur peut être assigné à un ou plusieurs rôles, et un rôle peut être assigné à un ou plusieurs utilisateurs. Cet arrangement fournis une grande flexibilité et granularité d'assignement des permissions aux rôles et des utilisateurs aux rôles. Sans cela il y a un risque qu'un utilisateur puisse obtenir plus d'accès aux ressources que nécessaire à cause du contrôle limité sur le type d'accès qui peut être associé avec les utilisateurs et les ressources. Les utilisateurs peuvent souhaiter lister les répertoires et modifier les fichiers existants, par exemple, sans créer de nouveaux fichiers, ou ils peuvent souhaiter ajouter des enregistrements à un fichier sant modifier d'enregistrements existants. Tout augmentation dans la flexibilité du contrôle d'accès aux ressources renforce également l'application du principe de moins de privilège.

Core RBAC
   Chaque session est un mappage d'un utilisateur à possiblement plusieurs rôles. Un utilisateur établis une session durant laquelle l'utilisateur active des sous-jeux de rôles auquel il est assigné. La fonction session_roles nous donne les rôle activés par la session et la fonction session_users nous donne l'utilisateur qui est associé avec une session. Les permissions disponibles à l'utilisateur sont les permissions assignées aux rôle qui sont actuellement actifs au travers de toutes les sessions utilisateur.

Hiérarchie RBAC

   Ce modèle introduit des hiérarchies de rôle (RH), communément inclus comme un aspect clé des modèles RBAC. Les hiérarchies sont un moyen naturel de structurer les rôles pour refléter les lignes d'autorité et de responsabilité d'une organisation.

   Les hiérarchies de rôle définissent une relation d'héritage avec les rôles. L'héritage a été décrit en terme de permission, par exemple, r1 hérite du rôle r2 si tous les privilèges de r2 sont également privilèges de r1. Pour certaines distribution de RBAC les permissions de rôle ne sont pas gérés centralement, bien que ces hiérarchies de rôle le soient. Pour ces systèmes, les hiérarchies de rôle sont gérés en terme de relations de contention utilisateur. Les rôle r1 contient le rôle r2 si tous les utilisateurs autorisés pour r1 sont également autorisés pour r2. Noter, cependant, que la contention d'utilisateur implique qu'un utilisateur de r1 ais (au moins) tous les privilèges de r2, alors que l'héritage de permissions pour r1 et r2 n'impliquent rient sur l'assignement de l'utilisateur.

hierarchical RBAC
   Ce standard reconnaît 2 types de hiérarchies de rôle - les hiérarchies de rôle générales et les hiérarchies de rôle limitées. Les hiérarchies de rôle générales fournissent un support pour un ordre arbitraire partiel pour servir de hiérarchie de rôle, pour inclure le concept d'héritage multiple des permissions et de membership via les rôles. Les hiérarchies de rôle limitées imposent des restrictions résultant en une structure plus simple (par exemple, un rôle peut avoir un ou plusieurs ascendants immédiats, mais est restreints à un seul descendant immédiat).

Hiérarchies de rôle générales

   Les hiérarchies de rôle générales supportent le concept d'héritage multiple, qui fournis la capacité d'hériter les permissions de 2 ou plusieurs rôles source et d'hériter des utilisateurs membre de 2 ou plusieurs rôles sources. l'héritage multiple fournis 2 propriétés de hiérarchie importantes. La première est la capacité de composer un rôle depuis plusieurs rôles subordonnés (avec moins de permissions) en définissant des rôles et relations qui sont caractéristiques de l'organisation et de structures métier, que ces rôle représentent. Ensuite, l'héritage multiple fournis un traitement uniforme des relations d'assignement utilisateur/rôle et des relations d'héritage rôle/rôle.

   Les rôle dans une hiérarchie de rôle limitée sont restreints à un simple descendant immédiat. Bien que les hiérarchies de rôle limités ne supportent pas l'héritage multiple, elles ne fournissent pas d'avantage administratif claire sur Core RBAC.

   Une hiérarchie de rôle générale peut être représenté en diagramme de Hasse. Les nœuds dans le graphique représent les rôles de la hiérarchie et il y a un ligne direct entre r1 et r2 si r1 est un descendant immédiat de r2.

Contraintes RBAC

   Les contraintes RBAC ajoute les relations de séparation des privilèges au modèle RBAC. Ces relation sont utilisées pour forcer un conflit d'interêt des stratégies que les organisations peuvent employer pour empêcher les utilisateurs d'excéder un niveau raisonnable d'autorité pour leur positions.

   Le conflit d'interêt dans un système basé sur les rôles peut se produire comme résultat d'un gain d'autorisation pour des permissions associés avec les rôles en conflit. Pour empêcher cette forme de conflit, la séparation de privilèges statique force les contraintes dans l'assignement des utilisateurs aux rôles. Les contraintes statiques peuvent prendre un variété de formes différentes.

   Les contraintes statiques définies dans ce modèle sont limitées à ces relations qui placent des restrictions dans les jeux de rôle et en particulier dans leur capacité à former les UA. Cela signifie que si un utilisateur est assigné à un rôle, l'utilisateur se voit refuser l'appartenance d'un second rôle. Une stratégie SSD peut être centralement spécifiée et imposée uniformément dans des rôles spécifiques.

   Les modèles RBAC ont définis des relations SSD en respect aux contraintes dans les assignements user-role sur des paires de rôles. Bien que dans le monde réel des stratégies SSD existent, cette définition est trop restrictive sous 2 aspects. D'abord, la taille du jeu de rôles dans le SSD et ensuit la combinaison des rôles dans le jeu pour lequel l'assignement utilisateur est restreint. Dans ce modèle, SSD est définis avec 2 arguments. Un jeu de rôle qui inclus 2 ou plusieurs rôles et une cardinalité supérieur à un indiquent une combinaison de rôle qui constiturait une violation de la stratégie SSD. Par exemple, une organisation peut exiger qu'aucun utilisateur ne puisse être assigné à 3 des 4 rôles qui représentent la fonction d'achat.

   Comme illustr ci-dessous, les relations SSD peuvent exister dans la hiérarchie RBAC. En appliquant des relations SSD dans la présence d'une hiérarchie de rôle, une attention particulière doit être appliquée pour s'assurer que l'héritage utilisateur n'amoindri pas les stratégies SSD. Ainsi, les hiérarchies de rôle ont été définis pour inclure l'héritage des contraintes SSD. Pour adresser cette inconsistance potentielle, SSD est définis dans les utilisateurs autorisés des rôles qui ont une relation SSD.

   Les relations SSD réduisent le nombre de permissions potentielles qui peuvent être faites à un utilisateur en plaçant des contraintes dans les utilisateurs qui peuvent être assignés à un jeu de rôles. Les relations de séparation de privilège dynamique (DSD), comme les relations SSD, sont prévues pour limiter les permissions qui sont disponibles à un utilisateur. Cependant, les relations DSD diffèrent des relations SSD par le contexte dans lequel ces limitations sont imposées. Les relations SSD définissent et placent les contraintes dans l'espace de permission total de l'utilisateur. Ce modèle définis les propriétés DSD qui limitent la capacité des permissions sur une espace de permission utilisateur en plaçant des contraintes dans les rôles qui peuvent être activés avec ou au travers d'une session utilisateur. Les propriétés DSD fournissent un support étendu pour le principe du moins de privilège dans cela que chaque utilisateur a différents niveaux de permissions à des moments différents, en fonction du rôle effectué. Ces propriétés s'assurent que les permissions ne persistent pas au-dela du temps requis pour la performance du privilège. Cet aspect du moins de privilège est sous réferré à une révocation en temps utile de privilège. La révocation dynamique des permissions peut être un problème plus complexe sans les facilités de la séparation dynamique de privilèges, et a été largement ignoré dans le passé.

   Ce modèle fournis la capacité de forcer une stratégie spécifique à une organisation de séparation dynamique des privilèges (DSD). Les relations SSD fournissent la capacité d'adresser de potentiels conflits d'interêt au moment où un utilisateur est assigné à un rôle. DSD permet à un utilisateur d'être autorisé pour 2 ou plusieurs rôles qui ne créent pas de conflit lorsqu'ils agissent indépendamment, mais produit un problème de stratégie quand activé simultanément. Par exemple, un utilisateur peut être autorisé pour les rôles de caissier et de contrôleur de caisse, RBAC exige que l'utilisateur abandonne le rôle de caissier et fermet son tirroir caisse avant de passer contrôleur. Tant que ce même utilisateur n'est pas autorisé à assumer ces 2 rôles simultanément, un conflit d'interêt ne peut pas se produire.

Dynamic Separation of Duty Relations

Système RBAC et spécification fonctionnelle administrative

   La spécification fonctionnelle RBAC spécifie les opérations administratives pour la création et la maintenance de jeux d'éléments et de relations RBAC; les fonctions administratives pour effectuer les requêtes administratives; et les fonctions système pour créer et gérer les attributs RBAC dans les sessions utilisateur et prendre les décisions de contrôle d'accès. Les fonctions sont définies avec une précision suffisante pour répondre aux besoins de conformité de test et d'assurance, tout en fournissant aux développeurs la capacité d'incorporer des fonctionnalités additionnelles pour répondre aux besoins des utilisateurs.

Commandes administratives pour Core RBAC

AddUser Cette commande créé un nouvel utilisateur RBAC. La commande est valide seulement si le nouvel utilisateur n'est pas déjà membre du jeu de données USERS. Ce jeu USERS est mis à jours. Le nouvel utilisateur ne possède pas de session au moment de sa création.
DeleteUser Cette commande supprime un utilisateur existant de la base RBAC. La commande est valide si et seulement si l'utilisateur à supprimer est un membre du jeu de données USERS. Les jeux de données USER et UA et la fonction assigned_users sont mis à jours. C'est une décision d'implémentation de savoir comment procéder avec les sessions possédés par l'utilisation à supprimer.
AddRole Cette commande crée un nouveau rôle. La commande est valide si et seulement si le nouveau rôle n'est pas déjà membre du jeu de données ROLES. Le jeu ROLES et les fonctions assigned_users et assigned_permissions sont mis à jours. Initialement, aucun utilisateur ou permission n'est assigné au nouveau rôle.
DeleteRole Cette commande supprime un rôle existant de la base RBAC. La commande est valide si et seulement si le rôle est membre du jeu de données ROLES. C'est une décision d'implémentation de décidé de la manière de procéder avec les sessions dans le rôle à supprimer sont actifs.
AssignUser Cette commande assigne un utilisateur à un rôle. La commande est valide si et seulement si l'utilisateur est un membre du jeu de données USERS et le rôle est membre du jeu de données ROLES, et que l'utilisateur n'est pas déjà assigné au rôle. Le jeu de données UA et la fonction assigned_users sont mis à jours pour refléter l'assignement.
DeassignUser Cette commande supprime l'assignement d'un utilisareur à un rôle. Cette commande est valide si et seulement si le rôle est un des rôles actif de l'utilisateur.
GrantPermission Cette commande octroie à un rôle la permission d'effectuer une opération sur un objet à un rôle. La commande peut être implémentée pour octroyer les permissions à un groupe correspondant à ce rôle, par ex., en définissant la liste de contrôle d'accès à l'objet en question.
RevokePermission Cette commande révoque la permission d'effectuer une opération sur un objet depuis le jeu de permissions assignés à un rôle. La commande peut être implémentée pour révoquer les permissions d'un groupe correspondant à ce rôle, par ex., en définissant la liste de contrôle d'accès de l'objet en question.

Fonctions système pour Core RBAC

CreateSession(user,session) Cette fonction créé une nouvelle session avec un utilisateur donné comme propriétaire et un jeu de rôle actif. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS et que le jeu de rôle actif est un sous-jeu des rôles assignés à cet utilisateur.
DeleteSession(user,session) Cette fonction supprime une session données avec un utilisateur. La fonction est valide si et seulement si l'identifiant de session est un membre du jeu de données SESSIONS, l'utilisateur est un membre du jeu de données USERS, et la session est possédée par l'utilisateur donné.
AddActiveRole Cette fonction ajoute un rôle comme rôle actif d'une session dont le propriétaire est l'utilisateur donné. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS et le rôle est membre du jeu de données ROLES, et l'identifiant de session est membre du jeu de données SESSIONS, et le rôle est assigné à l'utilisateur, et la session est possédée par l'utilisateur.
DropActiveRole Cette fonction supprime un rôle du jeu de rôle actif d'une session possédé par un utilisateur donné. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS, l'identifiant de session est un membre du jeu de données SESSION, la session est possédées par l'utilisateur, et le rôle est un rôle actif de cette session.
CheckAccess Cette fonction retourne une valeur booléenne indiquant si le sujet d'une session données est autorisée ou non à effectuer l'opération données sur l'objet donné. La fonction est valide si et seulement si l'identifiant de session est un membre du jeu de données SESSIONS, l'objet est un membre du jeu de données OBJS, et l'opération est un membre du jeu de données OPS. Le sujet de la session a la permission d'effectuer l'opération sur cet objet si et seulement si cette permission est assignée à (au moins) un des rôles actifs de la session. Une implémentation peut utiliser les groupes qui correspondent aux rôle actifs du sujet et leur permission comme enregistré dans la liste de contrôle d'accés de l'objet.

Fonctions d'examen pour Core RBAC

AssignedUsers Cette fonction retourne le je d'utilisateurs assignés à un rôle donné. La fonction est valide si et seulement si le rôle est un membre du jeu de données ROLES.
AssignedRoles Cette fonciton retourne le je de rôles assignés à l'utilisateur donné. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS.

Fonctions d'examen avancé pour Core RBAC

RolePermissions Cette fonction retourne le jeu de permissions (op,obj) octroyés à un rôle donné. La fonction est valide si et seulement si le rôle est un membre du jeu de données ROLES.
UserPermissions Cette fonction retourne les permissions qu'un utilisateur obtient via ses rôles assignés. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS.
SessionRoles Cette fonction retourne les rôles actifs associés avec une session. La fonction est valide si et seulement si l'identifiant de session est un membre du jeu de données SESSIONS.
SessionPermissions Cette fonction retourne les permissions de la session, par ex., les permission assignées à ses rôles actifs. La fonction est valide si et seulement si l'identifiant de session est un membre du jeu de données SESSIONS.
RolesOperationsOnObject Cette fonction retourne le jeu d'opérations d'un rôle donné autorisé sur un objet donné. Cette fonction est valide seulement si le rôle est un membre du jeu de données OBJS
UserOperationsOnObject Cette fonction retourne le jeu d'opérations qu'un utilisateur donné est autorisé à effectuer sur un objet donné, obtenu soit directement ou via ses rôles assignés. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS et l'objet est un membre du jeu de données OBJS.

Commandes administratives pour les hiérarchies de rôles générales

AddInheritance Cette commande établis une nouvelle relation d'héritage immédiat entre les rôle. La commande est valide si et seulement si les 2 rôles sont membres du jeu de données ROLES.
DeleteInheritance Cette commande supprime une relation d'héritage immédiat existante. Cette commande est valide si et seulement si les rôles sont membre du jeu de données ROLES.
AddAscendant Cette commande créé un nouveau rôle r_asc, et l'insert dans la hiérarchie de rôle comme ascendant immédiat du rôle existant r_desc. La commande est valide si et seulement si r_asc n'est pas membre du jeu de données ROLES, et r_desc est un membre du jeu de données ROLES.
AddDescendant Cette commande créé un nouveau rôle r_desc, et l'insert dans la hiérarchie de rôle comme descendant immédiat du rôle existant r_asc. La commande est valide si et seulement si r_desc n'est pas membre du jeu de données ROLES, et r_asc est un membre du jeu de données ROLES.

Fonctions système pour les hiérarchies de rôles générales

CreateSession(user,session) Cette fonction créé une nouvelle session avec un utilisateur donné comme propriétaire, et un jeu donné de rôles actifs. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS, et le jeu de rôle actif est un sous-jeu autorisé pour cet utilisateur. Noter que si un rôle est actif pour une session, ses descendants ne sont pas nécessairement actifs pour cette session. Dans une implémentation RBAC, les rôles actifs d'une session peuvent être les groupes qui représentent ces rôles.
AddActiveRole Cette fonction ajoute un rôle comme rôle actif d'une session dont le propriétaire est un utilisateur donné. La fonction est valide si et seulement si l'utilisateur est membre du jeu de données USERS, le rôle est membre du jeu de données ROLES, l'identifiant de session est membre du jeu de données SESSIONS, l'utilisateur est autorisé pour ce rôle, et la session est possédée par cet utilisateur.

Fonctions d'examen pour les hiérarchies de rôles générales

   Toutes les fonctions de la section "Fonctions d'examen pour Core RBAC" sont valides. Cette section définis les fonctions suivantes:

AuthorizedUsers Cette fonction retourne le jeu d'utilisateurs autorisés pour un rôle donné, par ex., les utilisateurs qui sont assignés à un rôle qui hérite du rôle donné. La fonction est valide si et seulement si le rôle donné est un membre du jeu de données ROLES.
AuthorizedRoles Cette fonction retourne le jeu de rôles autorisés pour un utilisateur donné. La fonction est valide si et seulement si l'utilisateur est un membre de jeu de données USERS.

Fonction d'examen avancé pour les hiérarchies de rôles générales

   Cette section redéfinis les fonction RolePermissions et UserPermissions de la section "Fonctions d'examen avancé pour Core RBAC". toutes les autres fonction de cette section sont valides.

RolePermissions Cette fonction retourne le jeu de permission(ob,obj) octroyé à ou hérité par un rôle donné. La fonction est valide si et seulement si le rôle est un membre du jeu de données ROLES.
UserPermissions Cette fonction retourne le jeu de permissions qu'un utilisateur obtient via ses rôles assignés. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS.
RoleOperationsOnObject Cette fonction retourne le jeu d'opérations qu'un rôle donné est autorisé à effectuer sur un objet donné. Le jeu contient toutes les opérations octroyées directement à ce rôle ou hérité par ce rôle depuis un autre rôle. La fonction est valide seulement si le rôle est un membre du jeu de données ROLES, et l'objet est un membre de jeu de données OBJS.
UserOperationsOnObject Cette fonction retourne le jeu d'opérations qu'un utilisateur est autorisé à effectuer sur un objet donné. Le jeu consiste de toutes les opérations obtenues par l'utilisateur directement, ou via ses rôle autorisés. La fonction est valide si et seulement si l'utilisateur est un membre de jeu de données USERS et l'objet est un membre du jeu de données OBJS.

Commandes administratives pour les hiérarchies de rôles limitées

   Cette section redéfinis la fonction AddInheritance de la section "Commandes administratives pour les hiérarchies de rôles générales". Toutes les autres fonctions de cette section restent valides

AddInheritance Cette commande établis une nouvelle relation d'héritage immédiate entre les rôles existants r_asc et r_desc. La commande est valide si et seulement si les rôles sont membre du jeu de données ROLES.

Fonctions système pour les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonctions système pour les hiérarchies de rôles générales" sont valides

Fonction d'examen pour les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonctions d'examen pour les hiérarchies de rôles générales" sont valides

Fonction d'examen avancé pour les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonctions d'examen avancé pour les hiérarchies de rôles générales" sont valides

Relations SSD

   La propriété de séparation des privilèges statique, tel que définis dans ce modèle, utilise une collection SSD de paires d'un jeu de rôle et un cardinalité associée. Cette section définis le nouveau type de données SSD, qui dans un implémentation peut être le jeu de noms utilisé pour identifier les paires dans la collection.

Commandes administratives pour les relations SSD

   Cette section redéfinis la fonction AssignUser de la section "Commandes administratives pour Core RBAC", et définis un nouveau jeu de fonctions spécifiques. Les autres fonction de cette section sont valides.

AssignUser Cette commande assigne un utilisateur à un rôle. La commande est valide si et seulement si l'utilisateur est membre du jeu de données USERS, le rôle est membre du jeu de données ROLES, l'utilisateur n'est pas déjà assigné au rôle, et les contraintes SSD sont satisfaites après assignement.
CreateSsdSet Cette commande créé un jeu SSD de rôle et définis la cardinalité n de ses sous-jeu qui ne peuvent pas avoir d'utilisateurs communs. La commande est valide si et seulement si le nom du jeu SSD n'est pas déjà utilisé, tous les rôle dans le jeu SSD sont membres du jeu de données ROLES, n est un nombre naturel supérieur ou égal à 2 et inférieur ou égal à la cardinalité du jeu de rôle SSD, et la containte SSD pour le nouveau rôle est satisfait.
AddSsdRoleMember Cette commande ajoute un rôle à un jeu SSD de rôles. La cardinalité associée avec le jeu de rôle reste inchangée. La commande est valide si et seulement si le rôle SSD existe, le rôle à ajouté est un membre du jeu de données ROLES mais pas membre du jeu de rôle SSD, et la contrainte SSD est satisfaite après l'ajout du rôle dans le jeu de rôle SSD.
DeleteSsdRoleMember Cette commande supprime un jeu de rôle SSD complètement. La commande est valide si et seulement si le jeu de rôle SSD existe.
SetSsdSetCardinality Cette commande définis la cardinalité associée avec un jeu de rôle SSD. La commande est valide si et seulement si le jeu de rôle SSD existe, et la nouvelle cardinalité est un nombre naturel supérieur ou égal à 2 et inférieur ou égal au nombre d'éléments du jeu de rôle SSD, et la contrainte SSD est satisfaite après avoir définis la nouvelle cardinalité.

Fonctions système pour SSD

   Toutes les fonctions de la section "Fonctions système pour Core RBAC" sont valides

Fonctions d'examen pour SSD

   Toutes les fonctions de la section "Fonctions d'examen pour Core RBAC" sont valide. De plus, les fonctions suivantes sont définis:

SsdRoleSets Cette fonction retourne la liste des jeux de rôle SSD.
SsdRoleSetRoles Cette fonction retourne le jeu de rôles d'un jeu de rôle SSD. La fonction est valide si et seulement si le jeu de rôle existe.
SsdRoleSetCardinality Cette fonction retourne la cardinalité associée avec un jeu de rôle SSD. La foncion est valide si et seulement si le jeu de rôle existe.

Fonctions d'examen avancé pour SSD

   Toutes les fonctions de la section "Fonctions d'examen avancé pour Core RBAC" sont valide.

Commandes administratives pour SSD avec les hiérarchies de rôle générales

   Cette section redéfinis les fonctions AssignUser et AddInheritance de la section "Commandes administratives pour les hiérarchies de rôles générales", et les fonctions CreateSsdSet, AddSsdRoleMember, SetSsdSetCardinality de la section "Commandes administratives pour les relations SSD". Les autres fonctions de ces 2 section sont valides.

AssignUser Cette commande assigne un utilisateur à un rôle. La commande est valide si et seulement si l'utilisateur est un membre du jeu de données USERS, et le rôle est un membre du jeu de données ROLES, et l'utilisateur n'est pas déjà assigné au rôle, et les contraintes SSD sont satisfaites après l'assignement.
AddInheritance Cette commande établis une nouvelle relation d'héritage entre les rôles existants r_asc, et r_desc. La commande est valide si et seulement si les rôles sont membres du jeu de données ROLES, r_asc n'est pas un ascendant direct de r_desc, _desc n'hérite pas de r_asc, et les contraintes SSD sont satisfaites après avoir établis l'héritage.
CreateSsdSet Cette commande créé un jeu SSD de rôle et les jeux de cardinalité associés n de ses sous-jeux qui n'ont pas d'utilisateurs communs. La commande est valide si et seulement si le nom du jeu SSD n'est pas déjà utilisé, tous les rrôles dans le jeu SSD sont membre du jeu de données ROLES, n est un nombre naturel supérieur ou égal à 2 et inférieur ou égal à la cardinalité du jeu de rôle SSD, et la contrainte SSD pour le nouveau jeu de rôle est satisfaite.
AddSsdRoleMember Cette commande ajoute un rôle à un jeu SSD de rôles. La cardinalité associée avec le jeu de rôle reste inchangée. La commande est valide si et seulement si le jeu de rôle SSD existe, et le rôe à ajouter est un membre du jeu de données ROLES mais pas membre du jeu de rôle SSD.
SetSsdSetCardinality Cette commande définis la cardinalité associée avec un jeu de rôle SSD. La commande est valide si et seulement si le jeu de rôle SSD existe, la nouvelle cardinalité est un nombre naturel supérieur ou égal à 2 et inférieur ou égal au nombre d'éléments du jeu de rôles SSD, et la containte SSD est satisfaite après avoir définis la nouvelle cardinalité.

Fonctions système pour SSD avec les hiérarchies de rôle générales

   Toutes les fonctions de la section "Fonctions système pour les hiérarchies de rôles générales" sont valides

Fonctions d'examens pour SSD avec les hiérarchies de rôle générales

   Toutes les fonctions des sections "Fonctions d'examen pour les hiérarchies de rôles générales" et "Fonctions d'examen avancé pour SSD" sont valides

Fonction d'examens avancé pour SSD avec les hiérarchies de rôle générales

   Toutes les fonctions de la section "Fonction d'examen avancé pour les hiérarchies de rôles générales" sont valides

Commandes administratives pour SSD avec les hiérarchies de rôle limitées

   Cette section redéfinis la fonction AddInheritance de la section "Commandes administratives pour SSD avec les hiérarchies de rôle générales". Toutes les autres fonctions de cette section sont valides.

AddInheritance Cette commande établis une nouvelle relation d'héritage immédiat entre les rôle r_asc et r_desc. La commande est valide si et seulement si les rôles sont membre du jeu de données ROLES, r_asc n'a pas de descendants, et r_desc n'hérite pas de r_asc.
[SECTION] name="Fonctions système pour SSD avec les hiérarchies de rôle limitées" table="paragraphes" imbrication="0"
Toutes les fonctions de la section "Fonctions système pour SSD avec les hiérarchies de rôle générales" sont valides.

Fonctions d'examens pour SSD avec les hiérarchies de rôle limitées

   Toutes les fonctions des sections "Fonctions système pour les hiérarchies de rôles générales" et "Fonctions d'examen pour SSD" sont valides

Fonction d'examens avancé pour SSD avec les hiérarchies de rôle limitées

   Toutes les foncions de la section "Fonction d'examen avancé pour les hiérarchies de rôles générales" sont valides.

Commandes administratives pour les relations DSD

   Toutes les fonctions de la section "Commandes administratives pour Core RBAC" sont valide. Cette section définis les fonctions supplémentaires suivantes:

CreateDsdSet Cette commande créé un jeu DSD de rôle et définis une cardinalité n associée. La contrainte DSD stipule que le jeu de rôle DSD ne peut pas contenir n rôle ou plus, actifs simultanément dans la même session. La commande est valide si et seulement si le nom du jeu DSD n'est pas déjà utilisé, tous les rôles dans le jeu DSD sont membre du jeu de données ROLES, n est un nombre naturel supérieur ou égal à 2 et inférieur ou égal à la cardinalité du jeu de rôle DSD, et la contrainte DSD pour le nouveau rôle est satisfaite.
AddDsdRoleMember Cette commande ajeute un rôle à un jeu de rôles DSD. La cardinalité associée avec le jeu de rôle reste inchangé. La commande est valide si et seulement si le jeu de rôle DSD existe, le rôle à ajouter est membre du jeu de données ROLES, mais non membre du jeu de rôle DSD, et la contrainte DSD est satisfaite après l'ajout du rôle dans le jeu de rôle DSD.
DeleteDsdRoleMember Cette commande supprime un rôle depuis un jeu de rôles DSD. La cardinalité associée avec le jeu de rôle reste inchangé. La commande est valide si et seulement si le jeu de rôle DSD existe, le rôle à supprimer est un membre du jeu de rôle DSD, et la cardinalité associée avec le jeu de rôle DSD est inférieur au nombre d'éléments du jeu de rôle DSD.
DeleteDsdSet Cette commande supprime un jeu de rôle DSD complètement. Cette commande est valide si et seulement si le jeu de rôle DSD existe.
SetDsdSetCardinality Cette commande définis la cardinalité associée avec un jeu de rôle DSD donné. La commande est valide si et seulement si le jeu de rôle DSD existe, la nouvelle cardinalité est un nombre naturel supérieur ou égal à 2 et inférieur ou égal au nombre d'éléments du jeu de rôle DSD, et la contrainte DSD est satisfaite après avoir définis la nouvelle cardinalité.
[SECTION] name="Fonctions système pour les relations DSD" table="paragraphes" imbrication="0"
Cette section redéfinis les fonctions CreateSession et AddActiveRole de la section "Fonctions système pour Core RBAC". Toutes les autres fonctions de cette section sont valides

CreateSession Cette fonction créé une nouvelle session dont le propriétaire est l'utilisateur donné et un jeu de rôles actif. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS et le jeu de role actif de la session est un sous-jeu des rôle assigné pour le propriétaire de la session, le jeu de rôle actif de la session est un sous-jeu des rôles assignés au propriétaire de la session, et le jeu de rôle actif de la session satisfait les contraintes DSD.
AddActiveRole Cette fonction ajoute un rôle comme rôle actif d'une session dont le propriétaire est un utilisateur donné. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS, le rôle est un membre du jeu de données ROLES, l'identifiant de session est membre du jeu de données SESSIONS, le rôle est assigné à cet utilisateur, et l'ancien jeu de rôle actif complété avec le rôle à activer satisfont les contraintes DSD, et la session est possédée par cet utilisateur.

Fonctions d'examen pour les relations DSD

   Toutes les fonction de la section "Fonctions d'examen pour Core RBAC" sont valide. De plus, cette section définis de nouvelles fonctions:

DsdRoleSets Cette fonction retourne la liste de tous les jeux de rôle DSD
DsdRoleSetRoles Cette fonction retourne le jeu de rôles d'un jeu de rôle DSD. La fonction est valide si et seulement si le jeu de rôle existe.
DsdRoleSetCardinality Cette fonction retourne la cardinalité associée avec un jeu de rôle DSD. La fonction est valide si et seulement si le jeu de rôle existe.

Fonctions d'examen avancé pour les relations DSD

   Toutes les fonctions de la section "Fonctions d'examen avancé pour Core RBAC" sont valides.

Commandes administratives pour les relations DSD avec les hiérarchies de rôle générales

   Toutes les fonctions des sections "Commandes administratives pour les hiérarchies de rôles générales" et "Commandes administratives pour les relations DSD" sont valides

Fonctions système pour les relations DSD avec les hiérarchies de rôle générales

   Cette section redéfinis les fonctions CreateSession et AddActiveRole de la section "Fonctions système pour Core RBAC". Toutes les autres fonctions de cette section sont valides

CreateSession Cette fonction créé une nouvelle session dont le propriétaire est l'utilisateur donné et un jeu de rôles actif. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS et le jeu de role actif de la session est un sous-jeu des rôle autorisés pour le propriétaire de la session, et le jeu de rôle actif de la session satisfait les contraintes DSD.
AddActiveRole Cette fonction ajoute un rôle comme rôle actif d'une session dont le propriétaire est un utilisateur donné. La fonction est valide si et seulement si l'utilisateur est un membre du jeu de données USERS, le rôle est un membre du jeu de données ROLES, l'identifiant de session est membre du jeu de données SESSIONS, le rôle est autorisé pour cet utilisateur, et l'ancien jeu de rôle actif complété avec le rôle à activer satisfont les contraintes DSD, et la session est possédée par cet utilisateur.

Fonctions d'examen pour les relations DSD avec les hiérarchies de rôle générales

   Toutes les fonctions des sections "Fonctions d'examen pour les relations DSD" et "Fonctions d'examen pour les hiérarchies de rôles générales" sont valides

Fonctions d'examen avancé pour les relations DSD avec les hiérarchies de rôle générales

   Toutes les fonctions de la section "Fonction d'examen avancé pour les hiérarchies de rôles générales" sont valides

Commandes administratives pour les relations DSD avec les hiérarchies de rôle limitées

   Toutes les fonctions des sections "Commandes administratives pour les hiérarchies de rôles limitées" et "Commandes administratives pour les relations DSD" sont valides

Fonctions système pour les relations DSD avec les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonctions système pour les relations DSD avec les hiérarchies de rôle générales" sont valides

Fonctions d'examen pour les relations DSD avec les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonctions d'examen pour les relations DSD avec les hiérarchies de rôle générales" sont valides

Fonctions d'examen avancé pour les relations DSD avec les hiérarchies de rôle limitées

   Toutes les fonctions de la section "Fonction d'examen avancé pour les hiérarchies de rôles générales" sont valides
^
14 juillet 2010




chcon

chcon

Change le contexte de récurité SELinux des fichiers spécifiés

OPTIONS

-h, --no-dereference affecte les liens symboliques au lieu des fichiers référencés
--reference=RFILE utilise le context de sécurité de RFILE au lieu de spécifier un contexte.
-R, --recursive Opère sur les fichiers et les répertoires récursivement.
-H si -R est spécifié et qu'un argument de la ligne de commande est un lien symbolique vers un répertoire, le traverse.
-L en mode récursif, traverse tous les liens symboliqes vers un répertoire.
-P Ne traverse aucun lien symbolique. mode par défaut.
-v, --verbose Affiche un diagnostique pour chaque fichier traité.
-u USER, --user=USER Définis l'utilisateur dans le contexte de sécurité cible.
-r ROLE, --role=ROLE Définis le role dans le contexte de sécurité cible
-t TYPE, --type=TYPE Définis le type dans le contexte de sécurité cible
-l RANGE, --range=RANGE Définit la plage dans le contexte de sécurité cible
^
25 mai 2017




keys.txt

keys.txt

Service de rétention de clé kernel

   Ce service autorise les clé cryptographiques, jetons d'authentification, mappage d'utilisateur inter-domaine, et similaire d'être mis en cache dans le kernel pour utiliser les systèmes de fichier et d'autres services kernel.

   Les portes-clés sont permis; ce sont des type spéciaux de clé qui peuvent maintenir des liens vers d'autres clés. Chaque processus a 3 souscription de porte clé standard qu'un service peut utiliser pour trouver des clés.

   Le service de clé peut être configuré ou activé avec "Security options"/"Enable access key retention support" (CONFIG_KEYS)

Présentation

   Dans ce contexte, les clés représentent des unités de données cryptographiques, des jetons d'authentification, porte clé, etc. Ils sont représenté dans le kernel pas la structure key.

   Chaque clé a un nombre d'attribut:

- un numéro de série
- un type
- une description
- des informations de contrôle d'accès
- une date d'expiration
- Un payload
- l'état

   Chaque clé reçois un numéro de série du type key_serial_t qui est unique pour la durée de vie de cette clé. Tous les numéros de série sont des entier 32bits positifs. Les programmes userspace peuvent utiliser le numéro de série d'une clé comme moyen d'y accéder, sujet à vérification des permissions.

   Chaque clé est d'un type définis. Les types doivent être enregistrés dans le kernel par un service kernel (tel qu'un système de fichier) avant que des clés de ce type puissent être ajoutées ou utilisées. Les programmes userspace définissent les nouveaux type directement. Les types de clé sont représentés dans le kernel par la structure key_type. cela définis un nombre d'opérations qui peuvent être effectuées sur une clé de ce type.

   Chaque clé a une description, qui devrait être une chaîne affichable. Le type de clé fournis une opération pour effectuer une correspondance entre la description dans un cré et une chaîne critère

   Chaque clé peut être définie pour expirer à un moment donné par la fonction d'instantiation du type. Les clés peuvent être immortelles.

   Chaque clé peut avoir un payload. C'est la quantité de données qui représente la clé. Dans le cas d'un porte-clé, c'est une liste de clés qui sont liées au trousseau; dans le cas d'une clé définie par l'utilisateur, c'est un blob de donnée arbitraire Ce payload n'est pas requis, et le payload peut, en fait, être simplement stocké dans la structure de clé elle-même

   Similairement, quand le userspace souhaite lire le contenu de la clé, si permis, une autre opération de type de clé sera appelée pour convertir le payload attaché à la clé en un blob de donnée.

   Chaque clé peut être dans un des états de base suivant:

- non-instancié. La clé existe, mais n'a pas de données attachée. Les clés demandée depuis le userspace sont dans cet état
- instancié: C'est l'état normal. La clé est formée, et a des donnée attachées
- Négative. C'est un état relativement court. La clé agit comme une note disant que l'appel précédent du userspace a échoué, et agit comme un accélérateur de recherche de clé. une clé négative peut être mise à jours vers un état normal.
- expiré. Les clé ont dépassés la durée de vie définie. Une clé expirée pour être mise à jours pour revenir à un état normal
- révoqué. Une clé est placée dans cet état par une action userspace.
- dead. Le type de clé a été désenregistré

Vue générale du service de clés

   Le service de clé fournis des fonctionnalité:

           Le service de clé définis 3 types de clé spéciaux

                keyring Keyring sont des clé spéciales qui contiennent une liste d'autres clé.
                user Une clé de ce type a une description et un payload qui sont des blobs arbitraires de données. Ils peuvent être manipulés par le userspace et ne sont pas prévus pour être utilisés par les services kernel
                logon Comme une clé user, une clé logon a un payload qui est un blob de données arbitraire. Il est prévue comme un emplacement pour stocker des secrets qui sont accessible au kernel mais pas aux programmes userspace

        Chaque processus souscrit à 3 keyrings: un keyring spécifie au thread, un keyring spécifique au processus, et un keyring spécifique à une session.
        Chaque user ID résident dans le système maintient 3 keyrings spéciaux: un spécifique à l'utilisateur et un spécifique à la session utilisateur.
        Chaque utilisateur a 2 quotas avec lesquel les clés qu'ils possèdent sont suivis. Une limite le nombre total de clé et de trousseaux, et l'autre limite la quantité totale d'espace qui peut être consommé par les descriptions et payload
        Il y a une interface d'appel système par laquelle les programmes peuvent créer et manipuler les clé et trousseaux.
        Il y a une interface kernel par laquelle les services peuvent enregistrer des type et rechercher des clés
        Il y a une manière pour qu'une recherche faite depuis le kernel revienne au userspace pour demander une clé qui ne peut pas être trouvée dans un trousseau de processus
        Un système de fichier optionnel est disponible via lequel la base de clé peuvent vue et manipulée

Permissions d'accès aux clés

   Les clé ont un propriétaire, un groupe d'accès, et un masque de permission. La masque a jusqu'à 8 bit chacun pour le processeur, utilisateur, groupe et les autres accès. Seul six de chaque jeu de 8bits sont définis. Ces permissions sont:

        View Permet de voir une clé ou un trousseau, incluant le type et description
        Read Permet de voir une le payload d'une clé, ou la liste des clé liées au trousseau
        Write Permet d'instancier un payload de clé ou de le mettre à jours, ou d'ajouter/supprimer un lien vers un trousseau.
        Search Permet de rechercher un trousseau et des clés.
        Link Permet de lier une clé ou un trousseau. Pour créer un lien d'un trousseau vers une clé, un processus doit avoir la permission Write sur le trousseau, et la permission Link sur la clé
        Set Attribute Permet de changer le masque de permissions

Support SELinux

   La classe de sécurité "key" a été ajoutée à SELinux pour que le contrôle d'accès puisse être appliqué aux clés créées dans divers contextes. Actuellement, toutes les permissions de base ci-dessus sont fournis dans SELinux, SELinux est simplement invoqué une fois les vérification de permissions de base effectuées.

   La valeur du fichier /proc/self/attr/keycreate influence le labéling des clés créées. Si le contenu de ce fichier correspont à un contexte de sécurité SELinux, la clé obtiendra ce contexte, sinon, la clé obtiendra le contexte courant de la tâche qui a invoqué la création de la clé. Les tâches doivent données explicitement les permissions à assigner à un contexte particulier aux clé nouvellement créées, en utilisant la permission "create" dans la classe de sécurité key.

   Les trousseaux par défaut associés avec les utilisateurs sont labélisés avec le contexte par défaut de l'utilisateur si et seulement si les programmes login ont été configurés correctement pour initialiser keycreate durant le processus de login. Sinon, il vont être labélisé avec le contexte du programme login lui même.

   Noter, cependant, que les trousseaux par défaut associés avec l'utilisateur root sont labélisés avec le contexte kernel par défaut, vu qu'ils sont créés très tôt dans le processus de boot, avant que root ait une chance de se connecter.

   Les trousseaux associés avec de nouveaux threads sont chacun labélisés avec le contexte de leur thread associés, et les trousseaux de session et de processus sont gérés de manière similaire.

Nouveaux fichiers procfs

   2 fichiers ont été ajoutés à procfs par lesquels un administrateur peut trouver le status du service de clé:

/proc/keys Liste les clé qui sont actuellement lisibles par la tâche lisant le fichier, en donnant les informations sur le type, description et permissions. Les clés incluse dans la liste sont celles dont la permission View est donné au processus qui lit le fichier. Noter que les vérifications de sécurité LSM sont effectuées, et peuvent filtrer les clés que le processus courant n'est pas autorisé à voir.


        Le contenu ressemble à:
SERIAL FLAGS USAGE EXPY PERM UID GID TYPE DESCRIPTION: SUMMARY
00000001 I----- 39 perm 1f3f0000 0 0 keyring _uid_ses.0: 1/4
00000002 I----- 2 perm 1f3f0000 0 0 keyring _uid.0: empty
00000007 I----- 1 perm 1f3f0000 0 0 keyring _pid.1: empty
0000018d I----- 1 perm 1f3f0000 0 0 keyring _pid.412: empty
000004d2 I--Q-- 1 perm 1f3f0000 32 -1 keyring _uid.32: 1/4
000004d3 I--Q-- 3 perm 1f3f0000 32 -1 keyring _uid_ses.32: empty
00000892 I--QU- 1 perm 1f000000 0 0 user metal:copper: 0
00000893 I--Q-N 1 35s 1f3f0000 0 0 user metal:silver: 0
00000894 I--Q-- 1 10h 003f0000 0 0 user metal:gold: 0

        I Instancié
        R Révoqué
        D Mort
        Q Contribut au quota de l'utilisateur
        U En construction
        N Clé négative

/proc/key-users Ce fichier liste les données pour chaque utilisateur qui a au moins une clé dans le système. De telles données incluent les informations de quota et des statistiques:


        [root@andromeda root]# cat /proc/key-users
0: 46 45/45 1/100 13/10000
29: 2 2/2 2/100 40/10000
32: 2 2/2 2/100 40/10000
38: 2 2/2 2/100 40/10000

        ‹UID› User ID
        ‹usage› Structure refcount
        ‹inst›/‹keys› Nombre total de clés et le nombre instanciées
        ‹key›/‹max› Quota - compteur de clé
        ‹bytes›/‹max› Quota - taille de clé

   4 nouveaux fichiers sysctl ont été ajoutés également pour contrôler les limites de quota:

/proc/sys/kernel/keys/root_maxkeys Nombre maximum de clés que root peut posséder
/proc/sys/kernel/keys/root_maxbytes Taille maximum en octets que root peut stocker dans ces clés
/proc/sys/kernel/keys/maxkeys Nombre total de clé qu'un utilisateur peut posséder
/pro/sys/kernel/keys/maxbytes Taille maximum en octets qu'une utilisateur peut stocker dans ces clés

Garbage collector

   Les clés morets (pour lesquelles le type a été supprimé) sont automatiquement unlinked des trousseaux et supprimés dès que possible par un collector en tâche de fond.

Similairement, les clé révoquées et expirées sont collectées, mais seulement au bout d'un certain temps. Ce délai est définis en secondes dans:
/proc/sys/kernel/keys/gc_delay
^
14 juillet 2010




runcon

runcon

Lance une commande dans le contexte de sécurité SELinux spécifié

   Si aucune option n'est spécifiée, le premier argument est utilisé comme contexte complet. Sans options ni commande, affiche le contexte de sécurité courant.

OPTIONS

-c, --compute Calcule le contexte de transission du processus avant de le modifier
-u USER, --user=USER Définis l'utilisateur dans le contexte de sécurité cible.
-r ROLE, --role=ROLE Définis le role dans le contexte de sécurité cible
-t TYPE, --type=TYPE Définis le type dans le contexte de sécurité cible
-l RANGE, --range=RANGE Définit la plage dans le contexte de sécurité cible
^
16 mai 2017




SELinux

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
Architecture SELinux haut-niveau
   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.
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
   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

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 =
   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

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
   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
Déclarations mlsconstain
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
   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
   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
   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
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.

   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


/. /.. 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
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
déclarations et règles de langage permis dans chaque type de fichier source - 2

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