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)
03 juillet 2017

htmlpdflatexmanmd




visudo

visudo

Éditer le fichier sudoers

   visudo édite le fichier sudoers de manière sûre, analogue à vipw. visudo lock le fichier et fournis des vérifications de base.

   Il y a une liste hardcodée d'un ou plusieurs éditeur que visudo utilise qui peut être remplacés par le paramètre editors. Cette liste est par défaut à 'vi'. Normalement, visudo n'honore pas VISUAL et EDITOR sauf si elles contiennent un éditeur dans la liste des éditeurs mentionnés.

   visudo parse le fichier sudoers après l'édition et ne sauve les changement que s'il n'y a pas d'erreur de syntaxe.

OPTIONS

-c, --check Mode vérification, vérifie la syntaxe, propriétaire et mode.
-f, --file=sudoers Spécifie l'emplacement du fichier sudoers
-q, --quiet mode silencieux
-s, --strict Vérification stricte. Si un alias est référencé mais n'est pas définis, ou s'il y a une boucle d'alias, génère une erreur.
-x, --export=output_file Exporte un sudoers dans un format JSON dans le fichier spécifié ou stdin si '-'
^
03 juillet 2017

htmlpdflatexmanmd




sudoreplay

sudoreplay

Rejouer les logs de session sudo

   sudoreplay rejout ou liste les logs créés par sudo. Il peut jouer les sessions en temps réel, ou en ajustant la vitesse.

   L'ID doivrait être une séquence à 6 chiffres et lettres majuscules, ou un motif matchant l'option iolog_file. Quand une commande est lancée via sudo avec log_output activée dans le fichier sudoers, la chaîne TSID=ID est loggée via syslog ou dans le fichier de log. L'ID peut également être déterminé en mode list.

   En mode list, sudoreplay peut être utilisé pour trouver un ID de session basé sur des critères tels que l'utilisateur, le tty ou la commande lancée:

\n, \r Saute au prochain évènement, utile pour les longues pauses
' ' Met en pause la sortie, appuyer un n'importe quelle touche pour relancer
Réduit la vitesse par 2
Double la vitesse

OPTIONS

-d, --directory=dir Répertoire des logs de session au lieu du défaut /var/log/sudo-io
-f, --filter=[stdin|stdout,stderr,ttyin,ttyout] Sélection quels types E/S afficher.
-l, --list [expr] Active le mode liste. Dans ce mode, sudoreplay liste les sessions disponibles dans un format similaire au format de log sudo, trié par nom de fichier ou séquence de nombre. Si une expression de recherche est spécifiée, restreint les ID qui sont affichés. Une expression est composée des prédicats suivants:

        command ‹pattern› Évalue à vrai si la commande match le motif spécifié
        cwd ‹dir› Évalue à vrai si la commande a été lancée dans le répertoire spécifié
        fromdate ‹date› Évalue à vrai si la commande a été lancée à ou après cette date
        group ‹runas_group› Évalue à vrai si la commande a été lancée sous le groupe spécifié
        runas ‹runas_user› Évalue à vrai si la commande a été lancée sous l'utilisateur spécifié
        todate ‹date› Évalue à vrai si la commande a été lancée avant la date spécifiée
        tty ‹tty› Évalue à vrai si la commande a été lancée dans le terminal spécifié
        user ‹user› Évalue à vrai si la commande a été lancée par l'utilisateur spécifié

           Les prédicats peuvent être combinées en utilisant les opérateurs and, or et !, ainsi que les parenthèses.

-m, --max-wait Spécifie une limite maximum d'attente entre les frappes de touche ou la sortie de données.
-s, --speed Spécifie le facteur de vitesse.

Format de date

   La date et l'heure peuvent être spécifié de plusieurs manières: HH:MM:SS am MM/DD/CCYY timezone, HH:MM:SS am Month, Day Year timezone, CCYY-MM-DD HH:MM:SS, DD Month CCYY HH:MM:SS

   Les dates suivantes sont valides:

now
tomorrow
yesterday il y a 24 heure
2 hours ago
next Friday
last week
a fortnight ago L'heure courante, mais il y a 14 jours
10:01 am 9/17/2009
10:01 am
10 10 heure du matin
9/17/2009
10:01 am Sep 17, 2009

Exemples

Lister les sessions lancées par millert
sudoreplay -l user millert
Lister les sessions lancées par bob avec une commande contenant la chaîne vi
sudoreplay -l user bob command vi
Lister les sessions lancées par jeff qui match l'expression régulière
sudoreplay -l user jeff command '/bin/[a-z]*sh'
Lister les sessions lancées par jeff ou bob dans la console
sudoreplay -l ( user jeff or user bob ) tty console
^
03 juillet 2017

htmlpdflatexmanmd




sudoers.ldap

sudoers.ldap

Configuration LDAP sudo

   En plus du fichier standard sudoers, sudo peut être configuré via LDAP. sudo n'a plus besoin de lire sudoers.

   La configuration sudoers est contenue dans le conteneur LDAP ou=SUDOers. Sudo recherche d'abord l'entrée cn=defaults dans le conteneur et parcours les attributs sudoOption.

   L'équivalent d'un sudoers dans LDAP est un sudoRole. Il consiste des attributs suivants:

sudoUser Un nom d'utilisateur valide, #‹UID›, %‹group›, %#‹GID›, +‹netgroup›, ou %:‹groupe non unix› %:#‹ID de groupe non unix›
sudoHost Nom d'hôte, IP, réseau ou +‹netgroup d'hôte›. ALL match tous les hôte.
sudoCommand Nom d'une commande et ses arguments, optionnellement préfixé par '!'
sudoOption Identique aux options globales, mais spécifiques au sudoRole
sudoRunAsUser user sous lequel la commande est lancée
sudoRunAsGroup Groupe sous lequel la commande est lancée
sudoNotBefore horodatage de début de validité du sudoRole
sudoNotAfter horodatage de fin de validité du sudoRole
sudoOrder Les entrées sudoRole LDAP n'ont pas d'ordre. sudoOrder est un entier utilisé pour trier les entrées qui matchent.

Anatomie de la recherche LADP sudoers

   En recherchant un sudoer utilisant LDAP il y a seulement 2 ou 3 requêtes LDAP par invocation. La première requête sert à parcourir les options globales. Le second sert à matche le nom de l'utilisateur et les groupes auquel l'utilisateur appartient. Si aucun match n'est retourné pour l'utilisateur ou les groupes, une 3ème requête retourne toutes les entrées contenant les netgroups de l'utilisateur et les groupes non-unix et vérifie si l'utilisateur appartient à l'un d'entre-eux.

   Si les entrées timées sont activées avec la directive SUDOERS_TIMED, les requêtes LDAP incluent un sous-filtre qui limite la recherche aux entrées qui satisfont les contraintes de temps.

   Si la directive NETGROUP_BASE est présente, les requêtes sont effectuées pour déterminer la liste des netgroups auquel l'utilisateur appartient avant la requête sudoers. Cela permet d'inclure la liste des netgroups dans les requêtes sudoers de la même manière qu'avec les groupes unix. La 3ème requête n'est pas effectuées sauf si un plugin group est également effectuée. Les requêtes LDAP sont effectuées par sudo comme suit:

1. Match tous les enregistrement nisNetgroup avec un nisNetgroupTriple contenant l'utilisateur, l'hôte et le domaine NIS. La requête matche les entrées nisNetgroupTriple avec la forme courte ou longue du nom de domaine ou aucun nom d'hôte. Si le domaine NIS est définis, la requête matche seulement les entrées qui incluent de domaine ou pour lequel il n'y a pas de domaine présent. Si le domaine NIS n'est pas définis, un wildcard est utilisé pour matcher tous domaine pas prend en compte que le schéma NIS utilisé par les serveurs LDAP peuvent ne pas supporter les wildcard pour nisNetgroupTriple.
2. Les requêtes répétées sont effectuées pour trouver tout enregistrement nisNetgroup imbriqués avec une entrée memberNisNetgroup qui réfère à un enregistrement déjà matché.

Différence entre les sudoers LDAP et non-LDAP

   Il y a quelques subtiles différences dans la comportement de sudoers utilisant LDAP. La plus grosse différence étant l'ordre des entrées et attributs retournés, qui sont contrôlés par sudoOrder.

Configurer ldap.conf

   sudo lit le fichier /etc/ldap.conf. Seuls ces options sont supportés par sudo:

BIND_TIMELIMIT Spécifie le temps en secondes d'attente de connection à un serveur LDAP.
BINDDN Identité, sous la formate d'un DN, à utiliser pour effectuer les opérations LDAP
BINDPW Mot de passe de BINDDN
DEREF Spécifie comment déréférencer les alias
HOST Nom du serveur LDAP
KRB5_CCNAME Chemin du cache d'accréditifs Kerberos 5
LDAP_VERSION Version du protocole LDAP
NETGROUP_BASE DN de base pour les recherches des netgroups
NETGROUP_SEARCH_FILTER Filtre de recherche des netgroupes
PORT Port du serveur LDAP
ROOTBINDDN DN pour les opérations LDAP privilégiées
ROOTUSE_SASL Active l'authentification SASL pour les traitements privilégiés
SASL_AUTH_ID utilisateur SASL pour la connection LDAP
SASL_MECH Liste de mécanismes SASL à utiliser
SASL_SECPROPS Propriétés de sécurité SASL
SSL Active TLS pour les communications LDAP
SUDOERS_BASE DN de base pour les recherches SUDO
SUDOERS_DEBUG Niveaux de débuggage pour les requêtes sudo
SUDOERS_SEARCH_FILTER Filtre de recherche pour les requêtes sudo
SUDOERS_TIMED Spécifie si sudoNotBefore et sudoNotAfter sont évalués
TIMELIMIT Délai en secondes d'attente d'une réponse LDAP
TIMEOUT Délai en secondes d'attente d'une réponse depuis divers API LDAP
TLS_CACERTFILE Certificat de l'autorité
TLS_CACERTDIR Répertoire contenant les certificats d'autorité
TLS_CERT Certificat client
TLS_CHECKPEER Vérifie le certificat du serveur
TLS_KEY Clé privée du client
TLS_CIPHERS Liste d'algorithmes de chiffrement TLS à utiliser
TLS_KEYPW Mot de passe pour déchiffrer la clé privée. Peut être en base64 (base64:dGVzdA==)
TLS_RANDFILE Source d'entropie
URI URI du serveur LDAP
USE_SASL Active l'authentification SASL
ROOTSASL_AUTH_ID Utilisateur SASL à utiliser avec ROOTUSE_SASL

Configurer nsswitch.conf

   sudo consulte nsswitch.conf puor spécifie l'ordre de recherce sudoers. sudo recherche une ligne commençant par sudoers: et l'utilise pour déterminer l'ordre de recherche. Noter que sudo n'arrête pas sa recherche après le premier match et le dernier match a précédence. Les sources suivantes sont reconnus:

files Lit le fichier /etc/sudoers
ldap Lit sudoers depuis LDAP

   De plus, l'entrée [NOTFOUND=return] court-circuite la recherche si l'utilisateur n'a pas été trouvé dans la source précédente

Intergration avec sssd

   Dans les systèmes avec System Security Service Daemon il est possible d'utiliser SSSD pour cacher les règles sudoers LDAP. pour utiliser sssd, il faut utiliser sssd au lieu de ldap dans l'entrées sudoers dans /etc/nsswitch.conf. Noter que /etc/ldap.conf n'est pas utilisé par sssd.
^
03 juillet 2017

htmlpdflatexmanmd




sudoers

sudoers

plugin de stratégie de sécurité de sudo par défaut

   Ce plugin détermine les privilèges sudo de l'utilisateur en lisant la stratégie dans /etc/sudoers. sudo consulte le fichier sudo.conf pour déterminer quelle stratégieet plugin charger.

   Les arguments du plugins sont les suivants:

ldap_conf=‹path› emplacement du fichier ldap.conf alternatif
ldap_secret=‹path› emplacement du fichier ldap.secret alternatif
sudoers_file=‹path› fichier sudoers alternatif
sudoers_uid=‹uid› UID du propiétaire du fichier sudoers
sudoers_gid=‹gid› GID du fichier sudoers
sudoers_mode=‹mode› mode du fichier sudoers en octal

Authentification Utilisateur

   La stratégie de sécurité sudoers nécessite que la plupart des utilisateurs s'authentifient eux-même avant d'utiliser sudo. Un mot de passe n'est pas requis si l'utilisateur invoquant est root, si l'utilisateur cible est le même que l'utilisateur invoquant, ou si la startégie a désactivé l'authentification pour la commande utilisateur ou pour l'utilisateur. À la différence de su, quand sudoers exige une authentification, il valide les accréditifs de l'utilisateur, pas de l'utilisateur cible. Cela peut être changé avec rootpw, targetpw et runaspw.

   Si un utilisateur qui n'est pas listé dans la stratégie tente de lancer une commande via sudo, un mail est envoyé aux autorités définies.

   Noter qu'aucun mail n'est envoyé si un utilisateur non-autorisé tente de lancer sudo avec -l ou -v sauf en cas d'erreur d'authentification. Cela permet aux utilisateurs de déterminer s'ils sont autorisés ou non à utiliser sudo. Toute tentative d'utiliser sudo est loggé.

   Si sudo est lancé par root, et que la variable SUDO_USER est définie, la stratégie sudoers utilise cette valeur pour déterminer qui est l'utilisateur actuel. Cela peut être utilisé par un utilisateur pour logger des commandes via sudo même quand un shell root a été invoqué.

   sudoers utilise des fichiers horodatés par utilisateur pour le caching d'accrédifits. Une fois un utilisateur authentifié, un enregistrement est écrit contenant l'uid utilisé pour s'authentifier, l'id de session du terminal et un horodatage. L'utilisateur peut ainsi utiliser sudo sans mot de passe pour une courte période de temps. Par défaut, sudoers utilise un enregistrement séparé pour chaque tty, qui signifie que les sessions login de l'utilisateur sont authentifiés séparément.

Logging

   sudoers peut logger toutes les tentatives, réussies ou non et les erreurs dans syslog, un fichier de log, ou les 2. sudoers est également capable de lancer une commande dans un pseudo-tty et logger toutes les entrées/sorties. L'entrée standard, la sortie standard, et l'erreur standard peuvent être loggés même s'ils ne sont pas associés avec un terminal. Le logging d'E/S n'est pas activé par défaut.

Environnement de commande

   vu que les variables d'environnement peuvent influencer le comportement des programmes, sudoers fournis un moyen de restreindre les variables de l'environnement utilisateur hérités par la commande à lancer. Il y a 2 manières distincts de gérer ces variables.

   Par défaut, l'option env_reset est activée, les commandes sont donc lancées dans un environnement minimal. Dans les systèmes Linux sans environnement PAM, l'environnement est initialisé avec le contenu de /etc/environment. Le nouvel environnement contient TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME et les variables SUDO_* en plus des variables de processus invoquant permis par env_check et env_keep. C'est une liste blanche de variables d'environnement. Les variables commençant pas () sont supprimées sauf si le nom et la valeur sont matché par env_keep ou env_check, vu qu'elles sont interprétées comme des fonctions par d'anciennes versions de bash

   Si, cependant, l'option env_reset est désactivé, toute variable non explicitement refusée par env_check et env_delete sont héritées depuis le processus invoquant. Dans ce cas, env_check et env_delete deviennet comme une blacklist. Les variable commençant pas () sont toujours supprimées. Vu qu'il n'est pas possible de blacklister toutes les variables d'environnement potentiellement dangereuses, le mode env_reset est préférable.

   Par défaut, les variables d'environnement sont matchés par leur nom. Cependant, si le motif inclus le signe '=', les noms des variables et leur valeur sont matchés.

   La liste complète des variables d'environnement que sudo autorise ou refuse est contenue dans la sortie de sudo -V quand lancé en root.

   Dans les systèmes qui supportent PAM où le module pam_env est activé pour sudo, les variables dans l'environnement PAM peuvent être fusionnées dans l'environnement. Si une variable dans l'environnement PAM est déja présente, la valeur est remplacée seulement si la variable n'était pas préservées par sudoers. quand env_reset est activé, les variables préservées depuis l'environnement de l'utilisateur invoquant par la liste env_keep a précédence sur l'environnement PAM. Quand env_reset est désactivé, les variables de l'environnement utilisateur ont précédence sur l'environnement PAM sauf en cas de match de la liste env_delete.

   Un cas spécial, si -i est spécifié, sudoers initialise l'environnement sans regarder la valeur de env_reset. DISPLAY, PATH et TERM ne sont pas changés; HOME, MAIL, SHELL, USER et LOGNAME sont basés sur l'utilisateur cible. Dans les systèmes Linux sans PAM, le contenu de /etc/environment est également inclus.

   Finalement, restricted_env_file et env_files sont appliqués, si présents. Les variables dans restricted_env_file sont appliqués en premier, et sont sujets aux même restrictions que l'environnement de l'utilisateur invoquant. Les variables env_file sont appliquées en dernier et ne sont pas sujettes à ces restrictions. Dans tous les cas, les variables présentes dans les fichiers ne sont définis à leur valeur spécifiées que si elles ne sont pas en conflit avec une variable d'environnement existante

Format du fichier sudoers

   Le fichier sudoers est composé de 2 types d'entrées: les alias et les utilisateurs. Quand plusieurs entrées correspondent à un utilisateur, elles sont appliquées dans l'ordre. En cas de multiple match, le dernier est utilisé.

Syntaxe EBNF

   EBNF contient les opérateurs suivants:

        ? Signifie que le symbole ou groupe de symbole précédent est optionnel, c'est à dire qu'il peut apparaître une fois ou pas du tout
        Signifie que le symbole ou groupe de symbole précédent peut apparaître 0 ou plusieurs fois
        + Signifie que le symbole ou groupe de symbole précédent peut apparaître une ou plusieurs fois

Aliases

Il y a 4 types d'alias: User_Alias, Runas_Alias, Host_Alias et Cmnd_Alias:
Alias ::= 'User_Alias' User_Alias (':' User_Alias)* |
    'Runas_Alias' Runas_Alias (':' Runas_Alias)* |
    'Host_Alias' Host_Alias (':' Host_Alias)* |
    'Cmnd_Alias' Cmnd_Alias (':' Cmnd_Alias)*
    
User_Alias ::= NAME '=' User_List
    
Runas_Alias ::= NAME '=' Runas_List
    
Host_Alias ::= NAME '=' Host_List
    
Cmnd_Alias ::= NAME '=' Cmnd_List
    
NAME ::= [A-Z]([A-Z][0-9]_)*

Une liste d'utilisateur consiste de noms d'utilisateurs, UID (préfixé avec '#'), groupes système et GID (préfixés avec '%' et '%#'), netgroups (préfixés par '+'), groupes non-unix (préfixés avec '%:' et '%:#') et de User_Alias. Chaque liste peut être préfixée avec '!'. les " permettent d'éviter le besoin d'échapper les caractères spéciaux, sinon ils doivent être spécifiés en hexa (ex: \x20)
User_List ::= User |
        User ',' User_List
    
User ::= '!'* user name |
        '!'* #uid |
        '!'* %group |
        '!'* %#gid |
        '!'* +netgroup |
        '!'* %:nonunix_group |
        '!'* %:#nonunix_gid |
        '!'* User_Alias

Une liste Runas_Alias est similaire à une User_List.
Runas_List ::= Runas_Member |
        Runas_Member ',' Runas_List
    
Runas_Member ::= '!'* user name |
        '!'* #uid |
        '!'* %group |
        '!'* %#gid |
        '!'* %:nonunix_group |
        '!'* %:#nonunix_gid |
        '!'* +netgroup |
        '!'* Runas_Alias

Une liste d'hôtes est faite d'un ou plusieurs noms d'hôte, adresses IP, réseaux, +netgroups, et d'autres alias.
Host_List ::= Host |
        Host ',' Host_List
    
Host ::= '!'* host name |
        '!'* ip_addr |
        '!'* network(/netmask)? |
        '!'* +netgroup |
        '!'* Host_Alias

   Une liste de commande est une liste d'un ou plusieurs nom de commandes, répertoires, et autres alias. Un nom de commande est un nom complet de fichier qui peut inclure des wildcard shell. Un simple nom de fichier permet de lancer une commande avec des arguments. Cependand, il est possible de spécifier les arguments (incluant des wildcard), ou "" pour indiquer que la commande peut seulement être lancée sans arguments. Un répertoire est un chemin complet se terminant par '/', et l'utilisateur pout exécuter tout fichier dans ce répertoire, mais pas dans les sous-répertoires

Si un Cmnd est associé avec des arguments de ligne de commande, les arguments dans Cmnd doivent matcher exactement avec ceux donnés par l'utilisateur. Noter que les caractères suivants doivent être échappés: ',’, ':’, '=’, '\’. La commande intégrée sudoedit est utilisée pour permettre à un utilisateur de lancer sudo avec -e. Il peut prendre des arguments. Noter que sudoedit est une commande intégrée dans sudo et doit être spécifié dans le fichier sudoers sans chemin.
digest ::= [A-Fa-f0-9]+ |
        [[A-Za-z0-9+/=]+
    
Digest_Spec ::= "sha224" ':' digest |
        "sha256" ':' digest |
        "sha384" ':' digest |
        "sha512" ':' digest
    
Cmnd_List ::= Cmnd |
        Cmnd ',' Cmnd_List

command name ::= file name |
        file name args |
        file name '""'
    
Cmnd ::= Digest_Spec? '!'* command name |
        '!'* directory |
        '!'* "sudoedit" |
        '!'* Cmnd_Alias

   Si un nom de commande est préfixé avec un Hash, la commande ne match que si le hash SHA2 est vérifié. Les formats suivants sont supportés: sha224, sha256, et sha512. La chaîne peut être spécifiée en hexa ou en base64.

Default

Certaines options de configuration ont une valeur par défaut qui peut être changé en temps réel via une ou plusieurs lignes Default_Entry. Cela peut affecter tous les utilisateurs dans tous les hôtes, tous les utilisateurs sur un hôte spécifique, un utilisateur spécifique, une commande spécifique, ou des commandes lancées par un utilisateur spécifiques.
Default_Type ::= 'Defaults' |
        'Defaults' '@' Host_List |
        'Defaults' ':' User_List |
        'Defaults' '!' Cmnd_List |
        'Defaults' '›' Runas_List
    
Default_Entry ::= Default_Type Parameter_List
    
Parameter_List ::= Parameter |
        Parameter ',' Parameter_List
    
Parameter ::= Parameter '=' Value |
        Parameter '+=' Value |
        Parameter '-=' Value |
        '!'* Parameter

   += et -= sont utilisés pour ajouter ou supprimer des éléments d'une liste. Les entrées sont parsée dans l'ordre suivant: generic, host, user, et runas, command. S'il y a plusieurs paramètres Default de même type, le dernier match est utilisé. Les paramètres Defaults suivant sont parsé avant tous les autres vu qu'ils affectent les entrées suivantes: fqdn, group_plugin, runas_default, sudoers_locale.

Spécification d'utilisateur


User_Spec ::= User_List Host_List '=' Cmnd_Spec_List \
        (':' Host_List '=' Cmnd_Spec_List)*
    
Cmnd_Spec_List ::= Cmnd_Spec |
        Cmnd_Spec ',' Cmnd_Spec_List
    
Cmnd_Spec ::= Runas_Spec? Option_Spec* Tag_Spec* Cmnd
    
Runas_Spec ::= '(' Runas_List? (':' Runas_List)? ')'
    
Option_Spec ::= (SELinux_Spec | Solaris_Priv_Spec | Date_Spec | Timeout_Spec)
    
SELinux_Spec ::= ('ROLE=role' | 'TYPE=type')
    
Solaris_Priv_Spec ::= ('PRIVS=privset' | 'LIMITPRIVS=privset')
    
Date_Spec ::= ('NOTBEFORE=timestamp' | 'NOTAFTER=timestamp')
    
Timeout_Spec ::= 'TIMEOUT=timeout'
    
Tag_Spec ::= ('EXEC:' | 'NOEXEC:' | 'FOLLOW:' | 'NOFOLLOW' |
        'LOG_INPUT:' | 'NOLOG_INPUT:' | 'LOG_OUTPUT:' |
        'NOLOG_OUTPUT:' | 'MAIL:' | 'NOMAIL:' | 'PASSWD:' |
        'NOPASSWD:' | 'SETENV:' | 'NOSETENV:')

   Une spécification d'utilisateur détermine quelles commandes un utilisateur peut lancer (et sous quel utilisateur). dans les hôte spécifiés. Par défaut, les commandes sont lancées en root. La structure de base est who where = (as_whom] what

Runas_Spec

   un Runas_Spec détermine l'utilisateur et/ou le groupe sous laquelle une commande peut être lancée. un Runas_Spec pleinement spécifié consiste de 2 Runas_List séparés par ':' et entre parenthèses. Le premier Runas_List indique sous quels utilisateurs la commande peut être lancée (comme avec sudo -u). Le second définis une liste de groupes qui peuvent être spécifié via sudo -g. Si les 2 Runas_List sont spécifié, la commande peut être lancée avec n'importe quelle combinaison d'utilisateurs et groupes listés dans leur Runas_list respectifs. Si seul le premier est listé, la commande peut être lancée par n'importe quel utilisateur dans la liste mais -g ne peut pas être spécifié. Si le premier Runas_List est vide, mais le second est spécifié, tous les utilisateurs peuvent lancer la commande avec le groupe définis à un listé. Si les 2 sont vides, la commande ne peut être lancée que sous l'utilisateur invoquant. Si Runas_Spec n'est pas spécifiée, la commande peut être lancée en root et aucun groupe ne peut être spécifié.

l'utilisateur dbg peut lancer ces 3 commandes, mais seulememt comme operator:
dgb boulder = (operator) /bin/ls, /bin/kill, /usr/bin/lprm
Il est également possible de remplacer Runas_Spec dans une entrée:
dgb boulder = (operator) /bin/ls, (root) /bin/kill, /usr/bin/lprm
On peut l'étendre peut permettre à dbg de lancer /bin/ls avec soit l'utilisateur soit le groupe à operator:
dgb boulder = (operator : operator) /bin/ls, (root) /bin/kill, /usr/bin/lprm
Noter que bien que la portion groupe permet à l'utilisateur de lancer la commande avec ce groupe, il ne force pas l'utilisateur à le faire. Si aucun groupe n'est spécifié, la commande sera lancée avec le groupe listé dans l'entrée de la base de mot de passe de l'utilisateur. Exemple de ce qui est permis par l'entrée ci-dessus:
sudo -u operator /bin/ls
sudo -u operator -g operator /bin/ls
sudo -g operator /bin/ls
Dans l'exemple suivant, l'utilisateur tcm peut lancer des commandes qui accèdent à un périphérique modem avec le groupe dialer
tcm boulder = (:dialer) /usr/bin/tip, /usr/bin/cu, /usr/local/bin/minicom
Seul le groupe est définis, la commande est lancée avec l'utilisateur tcm
sudo -g dialer /usr/bin/cu
Plusieurs utilisateurs et groupeg peuvent être présents dans un Runas_Spec, auquel cas l'utilisateur peut sélectionner une combinaison d'utilisateurs et groupes via -u et -g
alan ALL = (root, bin : operator, system) ALL
alan peut lancer une commande soit en root, soit bin, optionnellement en définissant le groupe operator ou system

Option_Spec

   un Cmnd peut avoir 0 ou plusieurs options. En fonction du système, les options peuvent consister de rôle/types SELinux, ou timeouts. Une fois une option définis pour une Cmnd, les Cmnd suivantes dans Cmnd_Spec_List héritent de cette option, sauf remplacé par une autre option.

   les règles sudoers peuvent spécifier une date de début et de fin via les paramètres NOTBEFORE et NOTAFTER. L'horodatage peut être spécifié en temps généralisé, rfc4517 (yyymmddHHMSSZ). Il est également possible de spécifier un offset en heures et minutes UTC. Par exemple '-0500' correspond à l'heure Eastern Standard aux US.

   Une commande peut avoir un timeout. S'il expire avant que la commande ne se soit terminées, la commande est terminées. Le timeout peut être spécifié en jours, heures, minutes et secondes (ex: 7d8h30m10s, 14d, 8h30m, 600s, 3600).

   Une commande peut avoir 0 ou plusieurs tags. Les valeurs de tag supportés sont: EXEC, NOEXEC, FOLLOW, NOFOLLOW, LOG_INPUT, NOLOG_INPUT, LOG_OUTPUT, NOLOG_OUTPUT, MAIL, NOMAIL, PASSWD, NOPASSWD, SETENV, et NOSETENV. Une fois un tag définis dans une Cmnd, les Cmnd suivants dans la Cmnd_Spec_List héritent de ce tag sauf si remplacé par le tag opposé.

        [NO]EXEC autorise à lancer un exécutable lié dynamiquement
        [NO]FOLLOW autorise à suivre les liens symboliques pour sudoedit uniquement
        [NO]LOG_INPUT Remplace l'option log_input
        [NO]LOG_OUTPUT Remplace l'option log_output
        [NO]MAIL Remplace la valeur de l'option mail_all_cmnds. N'a pas d'effet avec -l ou -v
        [NO]PASSWD Exige que l'utilisateur s'authentifie lui-même avant de lancer une commande
        [NO]SETENV Remplace la valeur de l'option SETENV

Wildcard

   sudo autorise les wildcard style shell dans les noms d'hôte, noms de chemins, et arguments de ligne de commande dans le fichier sudoers:

        Matche un jeu de 0 ou plusieurs caractères
        ? Matche un simple caractère
        [...] Matche un des caractères
        [!...] Matche tout caractère non listé
        \x pour spécifier les caractères '*','?','[' et ']'

Inclure d'autres fichiers

   Il est possible d'inclure d'autres fichiers sudoers avec les directives #include et #includedir.

Autres caractères spéciaux et mots réservés

   '#' est utilisé pour indiquer un commentaire (excepté pour #include et #includedir ou dans le contexte d'un nom d'utilisateur suivi par un ou plusieurs chiffres).

   Le mot réservé ALL est un alias intégré qui implique qu'un match réussi toujours.

   '!' peut être utilisé comme opérateur NOT dans une liste.

Options sudoers

   sudo peut être modifié par des lignes Default_Entry:

always_query_group_plugin (bool) si un group_plugin est configuré, l'utilise pour résoudre les groupe sous la forme %group tant que ce n'est pas également un groupe système. Normalement, seules les groupes sous la forme %#group sont passé au group_plugin
always_set_home (bool) activé, sudo définis HOME au répertoire home de l'utilisateur cible
authenticate (bool) définis, les utilisateurs doivent s'authentifier eux-même avant de lancer des commandes
closefrom_override (bool) définis, l'utilisateur peut utiliser sudo -C qui remplace le point de départ par défaut auquel sudo commence à fermer les descripteurs de fichier.
compress_io (bool) définis, si sudo est configuré pour logger l'entrée ou la sortie d'une commande, les logs I/O sont compressés avec zlib.
exec_background (bool) par défaut, sudo lance une commande en foreground tant que sudo est lui-même en foreground. à on et la commande lancé dans un pty (dû au logging I/O ou du flag use_pty), la commande est lancées en tâche de fond.
env_editor (bool) Définis, visudo utilise la valeur de EDITOR ou VISUAL comme liste d'éditeur par défaut
env_reset (bool) définis, lance la commande dans un environnement minimal
fast_glob (bool) utilise la fonction fnmatch(3) au lieu de glob(3) pour le globbing, ce qui est plus rapide, mais n'est pas capable de matcher les chemins relatifs
fqdn (bool) place les noms ftdn dans le fichiers sudoers quand le nom d'hôte local ne contient pas de nom de domaine.
ignore_audit_errors (bool) autorise à lancer les commandes même si sudoers ne peut écrire dans le log d'audit
ignore_dot (bool) définis, ignore "." ou "" dans la variable PATH
ignore_iolog_errors (bool) autorise à lancer des commandes même si sudoers ne peut écrire dans le fichier de log E/S
ignore_logfile_errors (bool) autorise à lancer des commandes même si sudoers ne peut écrire dans le fichier de log
ignore_local_sudoers (bool) Si définis via LDAP, ne parse pas /etc/sudoers
ignore_unknown_defaults (bool) ne produit pas d'alerte si une entrée Defaut inconnue est rencontrée, ou une options sudoOptions dans LDAP.
insults (bool) insulte les utilisateurs quand ils entrent un mot de passe incorrect
log_host (bool) Définis, le nom d'hôte est loggé
log_input (bool) Définis, log l'entrée utilisateur
log_output (bool) Définis, log la sortie envoyée à l'écran
log_year (bool) Définis, log l'année au format yyyy
long_otp_prompt (bool) En validant un schéma OTP, un prompt à 2 lignes est utilisé pour simplifier le copier/coller du challenge.
mail_all_cmnds (bool) Envoie un mail à chaque tentative d'exécution d'une commande (excepté avec -l ou -v et une authentification réussie)
mail_always (bool) envoie un mail à chaque fois qu'un utilisateur lance sudo.
mail_badpass (bool) Envoie un mail en cas de mot de passe incorrect
mail_no_host (bool) définis, envoie un mail si l'utilisateur invoquant existe dans le fichier sudoers mais n'est pas autorisé à lancer les commandes dans l'hôte courant.
mail_no_perms (bool) Définis, envoie un mail si l'utilisateur invoquant est autorisé à utiliser sudo, mais n'a pas l'autorisation de lancer la commande
mail_no_user (bool) Définis, envoie un mail si l'utilisateur invoquant n'est pas dans le fichier sudoers
match_group_by_gid (bool) par défaut, sudoers recherche chaque groupe dont l'utilisateur est membre par son GID pour déterminer le nom du groupe. Dans les systèmes ou la recherche des groupes est longue, cette option évite de résoudre les GID en noms de groupe
netgroup_tuple (bool) Définis, la recherche de netgroup est effectuée en utilisant les triplets netgroup
noexec (bool) Définis, toutes les commande lancées via sudo fonctionne comme avec le tag NOEXEC
pam_session (bool) Créé une nouvelle session PAM pour la commande à lancer
pam_setcred (bool) tente d'obtenir les accréditifs de l'utilisateur cible
passprompt_override (bool) Demande le mot de passe spécifié par passprompt est seulement utilisé si le prompt fournis par PAM match la chaîne "Password:". si definis, passprompt est toujours utilisé.
path_info (bool) informe quand la commande ne peut pas être trouvée dans le PATH.
preserve_groups (bool) par défaut, sudo initialise le vecteur de groupe à la liste des groupes de l'utilisateur cible. Définis, le vecteur de groupe de l'utilisateur n'est pas altéré. Le GID réel et effectif continuent de matcher l'utilisateur cible
pwfeedback (bool) Fournis un retour visuel en tapant un mot de passe
requiretty (bool) définis, sudo n'est lancé que si l'utilisateur est loggé dans un vrai tty.
root_sudo (bool) Définis, root est autorisé à lancer sudo. Désactivé, empêche sudoedit
rootpw (bool) Définis, sudo demande le mot de passe root au lieu du mot de passe de l'utilisateur invoquant
runaspw (bool) Définis, sudo demande le mot de passe de l'utilisateur définis par runas_default au lieu du mot de passe de l'utilisateur invoquant
set_home (bool) Définis et sudo invoqué avec -s, HOME est définis au home de l'utilisateur cible
set_logname (bool) Définis LOGNAME. Cependant pour certains programmes (incluant RCS) utilisent LOGNAME pour déterminer la vrai identité de l'utilisateur.
set_utmp (bool) Activé, sudo créé une entrée dans utmp ou utmpx quand un pseudo tty est alloué.
setenv (bool) Autorise l'utilisateur à désactiver l'option env_reset avec l'option -E
shell_noargs (bool) Définis et sudo est invoqué sans arguments, agit comme avec -s: lance un shell en root
stay_setuid (bool) Normalement, quand sudo exécute une commande, les UID réel et effectifs sont définis à l'utilisateur cible. Cette option laisse l'UID réel à l'utilisateur invoquant
sudoedit_checkdir (bool) Définis, sudoedit vérifie tous les composants répertoire du chemin à éditer pour vérifier s'il est en écriture par l'utilisateur. Les liens symboliques ne sont pas suivis et sudoedit refuse d'éditer un fichier localisé dans un répertoire accessible en écriture. Non effectif pour root.
sudoedit_follow (bool) Suit les liens symboliques en ouvrant les fichiers.
targetpw (bool) Définis, demande le mot de passe de l'utilisateur spécifié par -u au lieu du mot de passe de l'utilisateur invoquant
tty_tickets (bool) Définis, les utilisateurs doivent s'authentifier pour chaque tty
umask_override (bool) Définis, sudo définis le umask spécifié dans le fichier sudoers sans modification
use_netgroups (bool) Définis, les netgroups peuvent être utilisé à la place d'un utilisateur ou hôte
use_pty (bool) Définis, sudo lance la commande dans un pseudo-tty même si aucun plugin I/O n'est définis
user_command_timeouts (bool) Définis, l'utilisateur peut spécifier un timeout sur la ligne de commande
utmp_runas (bool) Définis, sudo stocke le nom de l'utilisateur runas en mettant à jours utmp au lieur du nom de l'utilisateur invoquant
visiblepw (bool) par défaut, sudo refuse de s'exécuter si l'utilisateur doit entrer un mot de passe mais qu'il n'est pas possible de désactiver l'écho dans le terminal. Cela permet de lancer des commande comme "ssh somehost sudo ls" vu que ssh n'alloue pas de tty par défaut en lançant une commande.
closefrom (int) Avant d'exécuter une commande, sudo ferme tous descripteur de fichier ouvert autre que 0-2. Spécifie un fd à partir duquel fermer les fd.
command_timeout (int) Délai maximum pour l'exécution d'une commande.
maxseq (int) Numéro de séquence maximum qui est substitué pour l'échappement "%{seq}" dans le fichier de log I/O.
passwd_tries (int) Nombre maximum de tentative pour entrer en mot de passe
syslog_maxlen (int) Par défaut, sudoers créé des messages de log jusqu'à 980 octets. Pour éviter de tronquer les messages, sudoers split les message supérieurs à syslog_maxlen.
loglinelen (int) Nombre de caractères par ligne de log. n'a pas d'effet pour syslog.
timestamp_timeout (int) Nombre de minutes avant de redemander un mot de passe.
umask (int) umask pour la création des fichier
badpass_message (string) Message affiché si un utilisateur entre un mot de passe incorrect
editor (string) Liste d'éditeurs autorisé pour visudo.
iolog_dir (string) Répertoire parent où construire le nom de chemin pour le répertoire de log I/O. Seulement utilisé si log_input et log_output sont activés. Les échappements suivants sont permis:

        %{seq} Étendu pour augmenter le numéro de séquence en base 36
        %{user} Étendu au login de l'utilisateur invoquant
        %{group} Étendu au GID réel de l'utilisateur invoquant
        %{runas_user} Étendu au login de l'utilisateur qui exécute la commande
        %{runas_group} Étendu au groupe qui exécute la commande
        %{hostname} Étendu au nom de l'hôte local sans le nom de domaine
        %{command} Étendu au nom de la commande lancée

iolog_file (string) Chemin du fichier de log, relatif à iolog_dir pour les logs I/O. Accepte les séquences d'échappement de iolog_dir
iolog_flush (string) Définis, sudo vide les données de log sur disque après chaque écriture au lieu de le même en tampon. Permet de voir les logs en temps réel.
iolog_group (string) Nom du groupe pour la créations des répertoires et fichiers de log I/O
iolog_mode (string) mode à utiliser pour créer les fichiers de log I/O
iolog_user (string) Propriétaire des répertoires et fichiers de log I/O
lecture_status_dir (string) Répertoire dans lequel sudo stocke les fichiers de status par utilisateur. Défaut: /var/adm/sudo/lectured
mailsub (string) Sujet du mail envoyé. %h étend au nom d'hôte
pam_login_service (string) Nom du service utilisé avec -i. Défaut: sudo
pam_service (string) Nom du service que PAM applique. Défaut: sudo
passprompt (string) Prompt par défaut à utiliser en demandant le mot de passe. Les échappements suivants sont supportés:

        %H Nom d'hôte local fqdn
        %h Nom d'hôte local
        %p utilisateur correspondant au mot de passe demandé
        %U Nom de l'utilisateur cible
        %u nom de l'utilisateur invoquant
        %% le caractère %

role (string) Rôle SELinux par défaut à utiliser en construisant un nouveau contexte de sécurité pour lancer la commande.
runas_default (string) Utilisateur par défaut pour lancer les commande.
sudoers_locale (string) Locale à utiliser pour parser le fichier sudoers, les commandes de logging, et l'envoie de mail.
timestampdir (string) Répertoire dans lequel sudo stocke ses fichiers d'horodatage.
timestampowner (string) Propriétaire du répertoire de status de lecture, d'horodatage et tous les fichiers qui y sont stockés.
type (string) Type SELinux par défaut pour construire un nouveau contexte SELinux
env_file (string) Spécifie le chemin complet d'un fichier contenant les variables d'environnement à définir pour le programme à lancer.
exempt_group (string) Les utilisateurs dans ce groupe sont exemptés du mot de path et des exigences PATH.
fdexec (string) Détermine si sudo exécute une commande par son chemin ou par un fd ouvers. always|never exécute ou non par fd, digest_only n'exécute par fd que si la commande a un digest associé.
group_plugin (string) plugin group sudoers avec des arguments optionnels.
lecture (string) Contrôle quand une lecture courte est affichée avec le prompt. always|never|once.
lecture_file (string) Fichier contenant le message à afficher au lieu du message embarqué
listpw (string) Contrôle quand un mot de passe est requis quand un utilisateur lance sudo -l:

        all Toutes les entrées de l'utilisateur pour l'hôte courant dans le fichier sudoers doivent avoir le flag NOPASSWD pour éviter d'entrée le mot de passe
        always L'utilisateur doit entrer un mot de passe pour utiliser -l
        any Au moins une entrée de l'utilisateur dans sudoers doit avoir le flag NOPASSWD pour ne pas entrer de mot de passe
        never L'utilisateur ne doit jamais entrer un mot de passe pour utiliser l'option -l
       

logfile (string) Chemin du fichier de log sudo.
mailerflags (string) flags à utiliser en invoquant mailer Défaut: -t
mailerpath (string) Chemin du programme pour envoyer les mails.
mailfrom (string) Adresse du champ From
mailto (string) Adresse de destination de mail
restricted_env_file (string) Fichier contenant les variables à définir dans l'environnement. Ces variables de manière similaires à l'environnement de l'utilisateur invoquant.
secure_path (string) Chemin de toutes les commandes lancées par sudo
syslog (string) facilité syslog pour les logs
syslog_badpri (string) Priorité sysloge quand l'utilisateur n'est pas autorisé à lancer une commande ou en cas d'echec de l'authentification
syslog_goodpri (string) Priorité syslog à utiliser quand l'utilisateur est autorisé à lancer une commande et que l'authentification a réussie.
verifypw (string) Contrôle quand un mot de passe est requis avec sudo -v:

        all Toutes les entrées dans le fichiers sudoers doivent avoir NOPASSWD pour éviter d'entrer un mot de passe.
        always L'utilisateur doit toujours entrer sont mot de passe pour utiliser l'option -v
        any Au moins une entrée dans le fichier sudoers pour l'utilisateur doit avoir le flag NOPASSWD pour éviter d'entrer un mot de passe
        never L'utilisateur n'a jamais besoin d'entrer un mot de passe

env_check (string) Variables d'environnement à supprimer sauf si elles sont sûres. Pour toutes les variables excepté TZ, sûre signifie que la valeur de la variable ne contient pas de '%' ou '/'
env_delete (string) Variables d'environnement à supprimer de l'environnement de l'utilisateur quand env_reset n'est pas effectif.
env_keep (string) Variables d'environnements à préserver de l'environnement de l'utilisateur quand env_reset est effectif

Plugins group

   sudoers supporte sa propre interface de plugin pour permettre de rechercher des groupes non-Unix dans une source autre que la base de groupe Unix standard. Celà permet d'implémenter la syntaxe nonunix_group.

   Les plugins group sont spécifiés via le paramètres group_plugin. Les plugins group suivants sont installés par défaut:

group_file.so Supporte un fichier de groupes alternatif qui utilise la même syntaxe que /etc/group. Le chemin du fichier doit être spécifié en arguments
system_group.so Supporte la recherche de groupe via getgrnam() et getgrid(). Il peut être utilisé dans le cas où des utilisateurs appartiennent à des groupes non-présents dans le vecteur groupe supplémentaire de l'utilisateur. Ce plugin n'a pas d'options

Format de log

   sudoers peut logger des évènements en utilisant syslog(3) ou un simple fichier. Le format est pratiquement identique dans les 2 cas.

Les commandes que sudo lance sont loggés en utilisant le format suivant:
date hostname progname: username : TTY=ttyname ; PWD=cwd ; USER=runasuser ; GROUP=runasgroup ; TSID=logid ; ENV=env_vars COMMAND=command

        date Date et heure à laquelle la commande a été lancée au format "MMM,DD,HH:MM:SS". Via syslog, le format de date est contrôllé par syslog. log_year permet d'inclure l'année
        hostname Le nom de l'hôte où sudo a été lancé. Seulement présent via syslog
        progname Le nom du programme, généralement sudo ou sudoedit. Seulement présent via syslog
        username Nom de login de l'utilisateur invoquant
        ttyname Nom court du terminal
        cwd Répertoire de travail courant
        runasuser Utilisateur sous lequel la commande est lancée
        runasgroup Groupe sous lequel la commande est lancée
        logid Identifiant de log I/O qui peut être utilisé pour rejouer la sortie des commande (log_input ou log_output doit être activé)
        env_vars variables d'environneent spécifiés sur la ligne de commande.
        command La commande exécutée

Entrées de log des commandes refusées

   Si l'utilisateur n'est pas autorisé à lancer la commande, la raison du refus suit le nom de l'utilisateur. Les raisons possibles sont:

        user NOT insudoers L'utilisateur n'est pas listé dans le fichie sudoers
        user NOT authorized on host L'utilisateur est listé dans le fichier sudoers mais n'est pas autorisé à lancer les commandes sur cet hôte
        command not allowed L'utilisateur est listé dans le fichier sudoers mais n'est pas autorisé à lancer la commande spécifiée
        3 incorrect password attemps L'utilisateur a échoué "passwd_trie" fois
        a password is required sudo -n a été spécifié, mais un mot de passe est requis
        sorry, you are not allowed to set the following environment variables L'utilisateur a spécifié des variables d'environnement sur la ligne de commande qui ne sont pas autorisés par sudoers

Entrées de log d'erreur

   Si une erreur se produit, sudoers log un message et, dans la plupart des cas, envoie un message à l'administrateur local via email. Les erreurs possibles incluent:

        parse error in /etc/sudoers near line N Erreur dans la configuration
        problem with defaults entries Options Defaults inconnus. N'empêche pas sudo de fonctionner
        timestamp owner (username): No such user l'utilisateur spécifié dans timestampowner n'a pas été trouvé dans la base de compte
        unable to open/read /etc/sudoers le fichier sudoers n'est pas accessible
        unable to open/read /etc/sudoers Le fichier /etc/sudoers n'existe pas
        /etc/sudoers is not a regular file Le fichier existe mais n'est pas un fichier régulier ou un lien symbolique
        /etc/sudoers is owned by uid N, should be 0 Le fichier n'est pas possédé par root
        /etc/sudoers is world writable Le fichier est accessible en écriture par tout le monde. Normalement il devrait être 0440
        /etc/sudoers is owned by gid N, should be 1 le fichier n'a pas le bon groupe.
        unable to open /var/run/sudo/ts/username sudoers n'arrive pas à lire ou créer le fichier d'horodatage pour l'utilisateur. Le répertoire parent doit être 0711
        unable to write to /var/run/sudo/ts/username sudoers n'arrive pas à écrire dans le fichier d'horodatage de l'utilisateur
        /var/run/sudo/ts is owned by uid X, should be Y Le répertoire ts est possédé par un utilisateur autre que timestampowner.
        /var/run/sudo/ts is group writable Le répertoire ts est accéssible en écriture par le groupe. Doit être 0700

Notes sur syslog

   Par défaut, sudoers log les messages via syslog. date, hostname et progname sont ajoutés par syslog, et non sudoers. ces informations peuvent donc varier d'un système à l'autre. La taille maximum des messages syslog varie également d'un système à l'autre. syslog_maxlen peut être utilisé pour changer la valeur par défaut de 980octets.

Notes sur le fichier de log

   Si logfile est activé, sudoers log dans un fichier local. sudoers utilise un format similaire à syslog, avec quelques différences importantes:

        - progname et hostname ne sont pas présents
        - si log_year est activé, l'année est incluse
        - Les lignes plus longue que loglinelen sont coupées et continées sur la ligne suivantes

Fichier de log d'E/S

   Quand le logging I/O est activé, sudo lance la commande dans un pseudo-tty et log toutes les E/S de l'utilisateur dans "iolog_dir" en utilisant un ID de session unique qui set inclus dans les logs, préfixé par "TSID=". Chaque log I/O est stocké dans un répertoire séparé qui contient les lignes suivantes:

        log Un fichier text contenant la date à laquelle la commande a été lancée, le nom de l'utilisateur invoquant, le nom de l'utilisateur cible, le nom du groupe cible, le terminal, le nombre de lignes et colonnes du terminal, le répertoire courant où la commande a été lancée et le chemin de la commande avec ses arguments.
        timing Un log de la quantité de temps, et le nombre d'octets, entre chaque entrées de log I/O.
        ttyin Entrée depuis le tty de l'utilisateur
        stdin Entrée depuis un pipe ou un fichier
        ttyout Sortie du pseudo-tty
        stdout Sortie standard dans un pipe ou redirigé dans un fichier
        stderr Erreur standard vers un pipe ou redirigé dans un fichier

   Tous les fichiers autre que log sont compressé au format gzip sauf si compress_io est désactivé. À cause du tampon, il n'est pas possible d'afficher les logs I/O en temps réel sauf si iolog_flush est utilisé.
  

   Vu que le log E/S de chaque session utilisateur est stocké dans un répertoire séparé, les utilitaires de rotation de log traditionnels ne peuvent pas être utilisés pour limiter le nombre de logs E/S. La manière la plus simple est d'utiliser l'option maxseq. Une fois la sequence atteinte, il est réinitialisé à 0 est sudoers tronque et réutilise les logs E/S existants.

Fichiers

/etc/sudo.conf Fichier de configuration de sudo
/etc/sudoers Fichier de stratégie de sudoers
/etc/group Fichier de groupes locaux
/etc/netgroup Liste des netgroups
/var/log/sudo-io Fichiers de log d'E/S
/var/run/sudo/ts Répertoire contenant les timestamps pour la stratégie de sécurité sudoers
/var/adm/sudo/lectured Répertoire contenant les fichiers de status de lecture pour la stratégie de sécurité sudoers
/etc/environment Environnement initial pour les système sans PAM

Notes de sécurité

- l'opération '!' ne doit pas être utilisé pour soustraire des commandes depuis AL, vu qu'il n'empêche pas d'exécuter ces commandes via un autre nom.
- fast_glob ne permet pas d'utiliser '!' correctement quand le chemin inclus du globbing.

Empêcher les échappements du shell

   Quand sudo exécute un programme, ce programme est libre de faire ce qu'il veut, incluant de lancer d'autres programmes. Cela peut être un problème de sécurité vu qu'il n'est pas commun pour un programme d'autoriser les échappements du shell, qui laisse un utilisateur bypasser le contrôle d'accès à sudo. Les programmes communs qui permettent les échappement du shell incluent les éditeurs, paginateurs, mails et terminaux. Il y a 2 approches à ce problème:

restrict Éviter de donner accès aux commande qui autorise un utilisateur à lancer des commandes arbitraires. De nombreux éditeurs ont des modes restreints qui désactive les échappements, bien que sudoedit est une meilleur solution aux éditeurs lancés via sudo.
noexec De nombreux systèmes qui supportent les librairies partagées ont la capacité de remplacer les fonctions par défaut en pointant une variable d'environnement (ex LD_PRELOAD) vers une librairie alternative. Dans de tels systèmes, la fonctionnalité noexec de sudo peut être utilisée pour éviter de lancer un programme qui exécute d'autres programmes.

Édition sécurisée

   Le plugin sudoers inclus sudoedit qui permet aux utilisateurs d'éditer les fichiers de manière sécurisée avec l'éditeur de leur choix. sudoedit est une commande intégrée et doit être spécifié dans le fichier sudoers dans chemin. Cependant, il peut prendre des arguments de ligne de commande. À la différence des autres commandes sudo, l'éditeur est lancé avec les permissions de l'utilisateur invoquant et avec l'environnement non-modifié.

   Les utilisateurs ne devraient jamais avoir les permissions sudoedit pour éditer un fichier qui réside dans un répertoire auquel l'utilisateur a accès en écriture, soit directement, ou via wildcard. Si l'utilisateur à ces droits, il peut remplacer le fichier avec un lien vers un autre fichier. Pour éviter cela, les liens symbolique ne sont pas suivis dans les répertoires en écriture (option sudoedit_checkdir).

Vérification du fichier timestamp

   sudoers vérifie le propriétaire de son répertoire d'horodatage et ignore le contenu du répertoire s'il n'est pas possédé par root, ou s'il est accessible en écriture par un utilisateur non-root.

   Bien que ce répertoire devrait être effacé au reboot, tous les systèmes ne contiennent pas de répertoire /var/run. Pour éviter de potentielles problèmes sudo ignore les fichiers timestamps antérieur au boot système.

   Certains systèmes avec des environnements graphiques permettent à des utilisateurs non-privilégiés de changer l'heure système. Vu que sudoers s'assure de l'horloge système pour la validation des horodatages, il peut être possible dans de tels systèmes qu'un utilisateur qui lance sudo pour une durée supérieur à timestamp_timeout en reculant l'horloge. Pour combattre cela, sudoers utilise une horloge monolitique pour ses horodatages si le système le supporte.

   Vu que les fichiers d'horodatage résident dans le système de fichier, ils peuvent survire à une session utilisateur. En résultat, un utilisateur peut être capable de se logger, lancer une commande avec sudo après s'être authentifié, se déconnecter, se reconnecter, et lancer sudo sans s'authentifier tant que l'horodatage est dans les 5 minutes. Quand l'option tth_tickets est activé, l'horodatage inclus le numéro de périphérique du terminal de l'authentification. Cela fournis une granularité par tth mais les horodatages continue à survivre entre les sessions. L'enregistrement d'horodatage inclus également l'ID de session du processus qui a été authentifié en dernier. Cela empêche les processus dans des session terminal différents d'utiliser le même enregistrement d'horodatage. Cela aide également à réduire les chances qu'un utilisateur soit capable de lancer sudo sans entrer un mot de passe en se déconnectant et revenant dans le même terminal.

Debuggage

   Le plugin sudoers support un framework de debuggage qui peut aider à suivre ce qu'il fait en interne s'il y a un problème. Cela peut être configuré dans le fichier sudo.conf

   sudoers utilise le même format de flag de debug que sudo. "subsystem@priority". Les priorités sont crit, err, warn, notice, diag, info, trace, debug. Les sous-systèmes suivant sont utilisés par sudoers:

alias traitements User_Alias, Runas_Alias, Host_Alias et Cmnd_Alias
all Match tous les sous-systèmes
audit Code d'audite Linux
auth Authentification utilisateur
defaults Paramètres Defaults
env Gestion de l'environnement
ldap sudoers basé sur LDAP
logging Support du logging
match Match des utilisateurs, groupes, hôtes et netgroups dans le fichier sudoers
netif Gestion des interfaces réseaux
nss Gestion nss dans sudoers
parser Parsing de fichier sudoers
perms Définition des permissions
plugin Équivalent de main pour le plugin
pty Code lié au pseudo-tty
rbtree redblack tree interne
sssd Sudoers basé sur sssd
util Fonctions utilitaires
^
03 juillet 2017

htmlpdflatexmanmd




sudo.conf

sudo.conf

Fichier de configuration de sudo

   sudo.conf supporte les directive 'Plugin', 'Path', 'Set', 'Debug'.

Plugin

Une ligne Plugin définis un module et son chemin, suivi de paramètres optionnels. Peut être spécifié plusieurs fois
Plugin sudoers_policy /usr/local/libexec/sudo/sudoers.so sudoers_mode=0440

Path

   Path définis les chemins vers divers librairies/programmes nécessaire. Si une ligne Path ne contient pas de chemin, la fonctionnalité est considérée désactivée:

        askpass chemin du helper pour lire les mots de passe quand aucun terminal n'est disponible
        noexec Chemin de la librairie wrappers pour les fonctions execl(), execle(), execlp(), exect(), execv(), execve(), execvP(), execvp(), execvpe(), fexecve(), popen(), posix_spawn(), posix_spawnp(), system(), et wordexp() qui empêche l'exécution d'autres commandes. Utilisé pour implémenter la foncionnalité noexec dans les systèmes qui supportent LD_PRELOAD ou son équivalent.
        plugin_dir Répertoire de recherche des plugins spéficier sans chemin complet.
        sesh Chemin de sesh. Utilé quand sudo est compilé avec le support SELinux

Set

disable_coredump true|false Par défaut sudo désactive le coredump pour éviter toute fuite de données sensible
group_source sudo passe la liste des groupes de l'utilisateur invoquant à la stratégie et les plugins I/O. Dans la plupart des système, il y a une limite du nombre de groupes (généralement 16). si la liste de groupe dépasse la limite kernel, sudo consulte lui-même la liste des groupes:

        static Utilise la liste de groupe statique que le kernel retourne
        dynamic Requête toujours la base de groupe. C'est dynamique dans le sens où les changements fait dans la base de groupe après que l'utilisateur se soit loggé sont reflétés dans la liste des groupe.
        adaptive Ne requête la pase que si la liste des groupes retournés par le kernel a atteind la limite des entrées.

max_groups Nombre maximum de groupes utiliateur à récupérer dans la base de groupe lorsque sudo requête la base de groupe directement
probe_interfaces Par défaut, sudo sont les interfaces réseaux du système et passe l'IP à chaque interface activée au plugin de stratégie. Cela simplifie les règles de match basé sur l'IP sans avoir à requêter DNS.

Debug

Une ligne Debug consiste du mot clé Debug, suivi par le nom du programme ou plugin à débugger (sudo, visudo, sudoreplay, sudoers), le nom du fichier de dibug et une liste de flags. Par exemple:
Debug sudo /var/log/sudo_debug all@warn,plugin@info

        all Match tous les sous-systèmes
        args traitement des arguments de la ligne de commande
        conv Conversation utilisateur
        edit sudoedit
        event Sous-système d'évènement
        exec exécution de commande
        main Fonction main de sudo
        netif Gestion des interfaces réseaux
        pcomm Communication avec le plugin
        pty Code lié au pty
        selinux gestion SELinux
        util Fonctions utilitaires
        utmp Gestion utmp
^
03 juillet 2017

htmlpdflatexmanmd




sudo

sudo, sudoedit

Exécute une commande sous un autre utilisateur

   sudo autorise un utilisateur à exécuter une commande en tant que super-utilisateur ou un autre utilisateur. L'utilisateur réel est utilisé pour déterminer le nom de l'utilisateur avec lequel vérifier la stratégie de sécurité

   sudo support une architecture à plugin pour les stratégies de sécurité et le logging. La stratégie de sécurité détermine quels privilèges un utilisateur a en lançant sudo. La stratégie peut exiger que l'utilisateur s'authentifie. La stratégie de sécurité par défaut est sudoers, qui est configuré via /etc/sudoers, ou via LDAP.

   Les stratégie de sécurité peuvent supporter le cache d'accréditifs pour permettre à l'utilisateur de lancer sudo pendant un certain temps sans retaper son mot de passe.

OPTIONS

-A, --askpass Normalement, si sudo exige un mot de passe, il le lis depuis le teminal de l'utilisateur. -A lance un helper
-b, --background Dans la commande en tâche de fond
-C, --close-from=num Ferme tous les descripteurs de fichier supérieur ou égal à ‹num› avant d'exécuter une commande. Les valeurs inférieur à 3 ne sont pas permises
-E, --preserve-env Indique à la stratégie de sécurité que l'utilisateur souhaite préserver ses variables d'environnement.
-e, --edit Édite un ou plusieurs fichiers
-g group, --group=group Lance la commande avec le groupe primaire spécifié au lieu du groupe primaire de l'utilisateur cible
-H, --set-home Demande que la stratégie définisse la variable HOME au répertoire spécifié par l'utilisateur cible
-h, --host=host Lance la commande sur l'ĥôte spécifié si le plugin de startégie de sécurité supporte les commandes distantes.
-i, --login Lance le shell de l'utilisateur cible. Cela signifie que les fichiers comme .profile ou .login sont lus. Si aucune commande n'est spécifiée, un shell interactif est lancé
-k, --reset-timestamp Utilisé sans commande, invalide les accréditifs cachés de l'utilisateur. En d'autres termes, la prochaine commande sudo nécessitera un mot de passe. Utilisé avec une autre option ou une commande, ignore les accréditifs en cache.
-K, --remove-timestamp Similaire à -k, excepté qu'il supprime les accréditifs cachés de l'utilisateur et ne peut pas être utilisé en conjonction avec une commande ou autre option
-l, --list Sans commande, liste les commandes permises (ou interdites) pour l'utilisateur invoquant, ou -U. Si une commande est spécifié et permise par la stratégie, le chemin comple de la commande est affichées avec les arguments.
-n, --non-interactive Empêche l'utilisateur d'entrer quoi que ce soit.
-P, --preserve-groups Préserve le groupe de l'utilisateur invoquant
-p, --prompt=prompt Utilise un prompt de mot de passe personnalisé:

        %H Étend le nom d'hôte incluant le nom de domaine
        %h Étend un nom d'hôte local sans le domaine
        %p Étend le nom de l'utilisateur dont le mot de passe est demandé
        %U Étend le nom de login de l'utilisateur cible
        %u Étend le nom de login de l'utilisateur invoquant
        %% le caractère '%'

-r, --role=role Lance la commande avec le contexte SELinux qui inclus le rôle spécifié
-S, --stdin Écrit le prompt sur stderr et lit le mot d-e passe depuis stdin au lieu du terminal
-s, --shell Lance le shell spécifié par la variable d'environnement SHELL si définie, ou le shell de l'utilisateur invoquant
-t, --type=type Lance la commande avec le contexte de sécurité SELinux qui inclus le type spécifié. Non spécifié, le type par défaut est dérivé du rôle
-U, --other-user=user avec -l, liste les privilèges de l'utilisateur
-T, --command-timeout=timeout Définis un timeout pour la commande
-u, --user=user Lance la commande sous cet utilisateur
-v, --validate Met à jours les accréditifs en cache de l'utilisateur
-- Indique la fin des arguments


   Les variables d'environnement à définir pour la commande peuvent également être passés sur la ligne de commande sous la forme VAR=value, sujettes à restriction.

Exécution de commande

   Quand sudo exécute une commande, la stratégie de sécurité spécifie l'environnement d'exécution pour la commande. Typiquement, l'uid et gid réel et effectif sont définis pour correspondre à l'utilisateur cible, tel que spécifié dans la base de comptes, et le vecteur groupe est initialisé avec la base de groupes.

  Les paramètres suivants peuvent être spécifiés par la stratégie de sécurité:

        UID effectif et réel
        GID effectif et réel
        GID supplémentaires
        La liste d'environnement
        Répertoire de travail courant
        Masque de création de fichier
        Role et type SELinux
        Priorité (nice)

   Quand sudo lance une commande, il se fork, définis l'environnement d'exécution, et appel execve dans le processus enfant. Le processus sudo principal attend que la commande soit complétée, puis passe le status de sortie de la commande à la fonction de fermeture de la stratégie de sécurité et quitte. Si un plugin de loggin est configuré ou si la stratégie de sécurité le demande explicitement, un nouveau pseudo-terminal est créé et un second process sudo est utilisé pour relayer les signaux de contrôle de job entre le pty de l'utilisateur et le nouveau pty. Ce processus rend possible, par exemple, se suspendre et résumer la commande. Sans cela, la commande dans un groupe de processus orphelin et ne reçevrai aucun signal de contrôle de job. Un cas spécial, si le plugin de stratégie ne définis pas de fonction close et aucun pty n'est requis, sudo exécute la commande directement au lieu de fork. le plugin sudoers ne définis une fonction close quand quand le loggin I/O est activé, un pty requis, ou les options pam_session ou pm_setcred sont activés.

Gestion des signaux

   Quand la commande est lancée comme enfant du processus sudo, sudo relai les signaux qu'il reçoit à la commande. Les signaux SIGINT et SIGQUIT sont seulement relayés quand la commande est lancées dans un nouveau pty ou quand le signal a été envoyé par un processus utilisateur, pas le kernel. Cela évite que la commande reçoive 2 fois SIGINT chaque fois que l'utilisateur utilise Contrôle-C. Certains signaux comme SIGSTOP et SIGKILL, ne peuvent être relayés à la commande. SIGTSTP doit être envoyé au lieu de SIGSTOP pour suspendre une commande.

   Un cas spécial, sudo ne relai pas les signaux qui sont envoyés par la commande lancée. Cela empêche la commande de se tuer elle-même. Dans certains systèmes, reboot(8) envoie SIGTERM à tous les processus non-système autre que lui-même avant de redémarrer le système. Celà empêche sudo de relayer SIGTERM, qui peut quitter avant que le système soit redémarré. En résultat, lancer un script qui appel reboot ou shutdown via sudo peut terminer le système dans un état indéfinis sauf si reboot ou shutdown sont lancés avec exec() au lieu de system().

   Si aucun plugin de loggin n'est chargé et que la stratégie n'a pas définis de fonction close, définir un timeout de commande ou que la commande soit lancé dans un nouveau pty, sudo peut exécuter la commande directement.

Plugins

   Les plugins peuvent être spécifiés via les directives Plugin dans sudo.conf. Ils peuvent être chargés comme objets partagés dynamiques ou compilés directement dans sudo. sudoers est le plugin par défaut

Valeur de sortie

   Le code de sortie de sudo est le code de sortie de la commande exécutée. Si la commande s'est terminée à cause d'un signal, sudo envoie lui-même le signal qui termine la commande.

   Sinon, sudo quitte avec une valeur de 1 s'il y a un problème de configuration/permission ou si sudo ne peut pas exécuter la commande. Dans le dernier cas, la chaîne d'erreur est affichée sur stderr. Si sudo ne peut pas stat(2) une ou plusieurs entrées dans le PATH de l'utilisateur, une erreur est affichée sur stderr.

Notes de sécurité

   Sudo tente d'être sûre en exécutant des commandes externes. Pour éviter le spoofing de commande, sudo vérifie "." et "" en dernier en recherchant une commande dans le PATH de l'utilisateur. Noter cependant que la variable PATH n'est pas modifée et est passée inchangée au programme que sudo exécute.

   Les utilisateurs ne devrait jamais obtenir des privilèges pour exécuter des fichiers qui sont en écriture par l'utilisateur ou qui résident dans un répertoire en écriture par l'utilisateur. Si l'utilisateur peut modifier ou remplacer la commande il n'y a pas de limite à ce qui peut être lancé.

   Noter que sudo normalement ne log que les commandes explicitement lancées. Si un utilisateur lance une commande telle que sudo su ou sudo sh, les commandes suivantes ne sont plus sujettes à la stratégie sudo. De même pour les commandes qui offrent des échappement shell. Si le loggin I/O est activé, les commandes suivantes sont loggées, mais il n'y a pas des logs traditionnels pour ces commandes. À cause de celà, une attention particulière doit être portée sur l'accès des utilisateurs aux commandes via sudo pour vérifier que la commande ne donne pas par inadvertance un shell root.

   Pour éviter la fuite d'information potentiellement sensible, sudo désactive les coredumps par défaut durant l'exécution.

Variables d'environnement

EDITOR Nom de l'éditeur par défaut pour -e (sudoedit), si SUDO_EDITOR ou VISUAL ne sont pas définis
MAIL Emplacement de la boite mail de l'utilisateur
HOME Répertoire personnel de l'utilisateur
LOGNAME Nom de l'utilisateur
PATH Les chemins de recherche pour les commandes
SHELL Shell courant de l'utilisateur
SUDO_ASKPASS Spécifie le chemin du helper pour lire le mot de passe si aucun terminal n'est disponible ou avec -A
SUDO_EDITOR Éditeur par défaut pour -e (sudoedit)
SUDO_GID GID de l'utilisateur qui a invoqué sudo
SUDO_PROMPT prompt pour les mots de passe
SUDO_PS1 valeur PS1 pour le programme à exécuter
SUDO_UID UID de l'utilisateur qui a invoqué sudo
SUDO_USER nom de login de l'utilisateur qui a invoqué sudo
USER nom de l'utilisateur
USERNAME idem à USER
VISUAL Éditeur par défaut pour -e (sudoedit) si SUDO_EDITOR n'est pas définis

Exemples

obtenir une liste des répertoire non-lisible:
sudo ls /usr/local/protected
Liste le répertoire personnel de l'utilisateur yaz dans une machine où le système de fichier maintenant ~ yaz n'est pas exporté en root
sudo -u yaz ls ~ yaz
Éditer index.html en tant qu'utilisateur www
sudoedit -u www ~ www/htdocs/index.html
Voir les logs système uniquement accessibles par root
sudo -g adm more /var/log/syslog
Lancer un éditeur en tant que jim avec un groupe primaire différent
sudoedit -u jim -g audio ~ jim/sound.txt
Éteindre la machine
sudo shutdown -r +15 "quick reboot"
^
16 mai 2017

htmlpdflatexmanmd




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.
SELinux supporte une stratégie modulaire, ce qui signifie qu'une stratégie n'a pas à être une grande stratégie, mais peut être construite avec des modules. Une stratégie modulaire consiste d'une stratégie de base qui contient les informations obligatoires, et 0 ou plusieurs modules de stratégie où chacune supporte une application particulière ou service. Ces modules sont compilés, liés et maintenus dans un magasin de stratégie. -
Pour être capable de construire la stratégie, une source de stratégie est requise, qui peut être fournie de 3 manières:

        - Un code source écrit en langage de stratégie SELinux.
        - En utilisant la statégie référence, qui a des macros haut-niveau pour définir les règles.
        - En utilisant CIL (Common Intermediate Language).
       

- Pour pouvoir compiler les sources de stratégie puis les charger dans le serveur de sécurité, un certains nombre d'outils sont requis
- Pour permettre à un administrateur de gérer les stratégies, l'environnement SELinux et les systèmes de fichier labélisés, outils et commandes gnu/linux modifiés sont utilisées.
- Pour s'assurer que les évènements de sécurité sont loggés, gnu/linux a un service d'audit qui capture les violations de stratégie.
- SELinux supporte les services réseaux.

Mandatory Access Control (MAC)

   MAC est un type de contrôle d'accès dans lequel le système d'exploitation est utilisé pour contraindre un utilisateur ou processus (le sujet) de l'accès ou un opération sur un objet (tel qu'un fichier, mémoire, etc.). Chaque sujet et objet a un jeu d'attributs de sécurité qui peuvent être interrogés par l'os pour vérifier si l'opération demandée peut être effectuée ou non. Pour SELinux:

- Les sujets sont des processus
- Les objets sont des ressources système tels que des fichiers, sockets, etc.
- Les attributs de sécurité sont des contextes de sécurité
- Le serveur de sécurité dans le kernel autorise l'accès ou non en utilisant la stratégie de sécurité qui décris les règles définies.

   Noter que le sujet ne peut pas décider de bypasser les règles de stratégie définie par la stratégie MAC avec SELinux. En contraste avec DAC de Linux, qui gouverne également la capacité des sujets à accéder aux objets, cependant il permet aux utilisateurs de décider de la stratégie. Les étapes dans les décisions DAC et MAC:

Traitement d
   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.

   homedir_template
   file_contexts

Le format du fichier file_contexts.template est comme suit:
pathname_regexp [file_type] opt_security_context

pathname_regexp Une entrée qui définis le chemin qui peut être une expression régulière
file_type Une des entrées optionnelles suivante: -b|c|d|p|l|s|-.
opt_security_context Cette entrée peut être soit le contexte de sécurité, incluant le niveau et plage MLS/MCS, ou la valeur ‹‹none›› pour indiquer que les fichiers qui matchent ne devraient pas être relabélisés

   Les mots clé qui peuvent être dans ce fichier sont:

HOME_ROOT Remplacé par le répertoire racine des répertoires personnels, normalement /home.
HOME_DIR Répertoire des répertoires personnels utilisateurs, défaut /home.
USER Remplacé par le user id
ROLE Remplacé par l'entrée 'prefix' du fichier de configuration users_extra qui correspond au user id des utilisateurs SELinux.

Exemple de file_contexts.template


/. /.. /.config /.hcwd /.local system_u:object_r:default_t:s0
/[^/]+ -- system_u:object_r:etc_runtime_t:s0
/a?quota\.(user|group) -- system_u:object_r:quota_db_t:s0
/nsr(/.*)? system_u:object_r:var_t:s0
/sys(/.*)? system_u:object_r:sysfs_t:s0
...
/etc/ntop.* system_u:object_r:ntop_etc_t:s0
HOME_DIR/.+ system_u:object_r:user_home_t:s0
/dev/dri/.+ -c system_u:object_r:dri_device_t:s0
...
/tmp/gconfd-USER -d system_u:object_r:user_tmp_t:s0
...
/tmp/gconfd-USER/.* -- system_u:object_r:gconf_tmp_t:s0
...
HOME_ROOT/\.journal ‹‹none››

modules/active/file_contexts Ce fichier devient les fichiers de stratégie contexts/files/file_contexts et est construit depui modules/active/file_contexts.template. Il est ensuite utilisé par les utilitaires de labéling de fichier pour s'assurer que les fichiers et répertoires sont labélisés en accord avec la stratégie.
modules/active/homedir_template Ce fichier est construit depuis les entrées dans le fichier file_contexts.template et utilisé par genhomedircon,semanage login, et semanage user pour générer des entrées utilisateurs dans le fichier file_contexts.homedirs
modules/active/file_contexts.homedirs Ce fichier devient le fichier de stratégie contexts/files/file_contexts.homedirs en construisant la stratégie. Il est ensuite utilisé par les utilitaires de label de fichier pour s'assurer que les répertoires home sont labélisés en accord avec la stratégie.
modules/active/netfilter_contexts & netfilter.local Ces fichiers ne sont pas utilisés pour le moment. Contiennent du code pour produire un fichier netfilter_contexts à utiliser par le services iptables.
modules/active/policy.kern Ce fichier binaire construite pas semanage ou semodule, qui devient la stratégie binaire policy/policy.[ver] qui sera chargé dans le kernel
modules/active/seusers.final & seusers Le fichier seusers.final mappe les utilisateurs GNU/Linux en utilisateurs SELinux et devient le fichier seusers. seusers.final est construit ou modifié en construisant une stratégie ou un fichier optionnel seusers est inclus dans le package de base ou par la commande semanage login.
modules/active/users_extra, users_extra.local, users.local users_extra et users_extra.local sont utilisés pour mapper un préfixe en répertoires personnels utilisateurs, où il est utilisé pour remplacer le mot clé ROLE. Le préfixe est lié à un utilisateur SELinux et devrait refléter le rôle de l'utilisateur. La commande semanage user permet d'ajouter un préfixe. users_extra contient toutes les entrées de préfixe de stratégie, et users_extra.local contient ceux générés par semanage user. users.local est utilisé pour ajouter de nouveaux utilisateurs SELinux à la stratégie sans éditer la stratégie.
modules/active/booleans.local Ce fichier est créé et mis à jours par semanage boolean et maintient les booléens
modules/active/file_contexts.local Ce fichier est créé et mis à jours par semanage fcontext et maintient les informations de contexte de fichiers et répertoires qui ne sont pas fournis par la stratégie core (ex: ne sont pas définis dans des fichiers .fc)
modules/active/interfaces.local Ce fichier est créé et mis à jours par la commande semanage interface et maintient les informations d'interface réseaux qui ne sont pas fournies par la stratégie core (ex: ne sont pas définis dans le fichier base.conf). Les nouvelles informations sont ensuite construites dans la stratégie par la commande semanage. Chaque ligne contient une déclaration netifcon.
modules/active/nodes.local Ce fichier est créé ni mis à jours par la commande semanage node et maintient des informations sur les adresses réseaux qui ne sont pas fournies par la stratégie core (ne sont pas définis dans base.conf). Ces informations sont ensuite construite dans la stratégie par la commande semanage. Chaque ligne contient une déclaration nodecon.
modules/active/ports.local Ce fichier est créé et mis à jours par semanage port et maintient les informations sur les port réseaux qui n'ont pas été fournis par la stratégie core. Chaque ligne contient une déclaration portcon
modules/active/preserve_tunables Ce fichier n'existe que si la stratégie construite préserve les personnalisations.
modules/active/disable_dontaudit Ce fichier n'existe que si la stratégie construite en ayant désactivé les règles dontaudit
modules/active/modules Ce répertoire contient des modules chargeable (‹module_name›.pp ou ‹module_name›.pp.disabled si désactivé) qui ont été construits par la commande semodule_package et placées dans le magasin par les commande semodule ou semanage module -a.

Fichiers de configuration de stratégie

   Chaque fichier dans cette section est relatif à /etc/selinux/‹policy_name›. La majorité des fichiers sont installés par la stratégie référence, semanage ou semodule. Il est possible de construire des stratégie monolitiques personnalisée qui utilisent seulement les fichiers installés dans cette zone (ex: n'utilise pas semanage ou semoduleè).

policy/policy.29 Stratégie binaire chargée dans le kernel
context/files/file_contexts Pour permettre au système de fichier d'être relabelisé
context/dbus_contexts Pour permettre au service de messagerie dbus à fonctionner sous SELinux
context/x_contexts Pour autoriser le service X-Windows à fonctionner sous SELinux

fichier seusers

   Le fichier seusers est utilisé par les programes login et par les utilisateurs GNU/Linux en utilisateurs SELinux. Une séquence de connexion serait:

- En utiliser le userid GNU/Linux, recherche re selinux_id dans ce fichier. S'il n'est pas trouvé, utilise l'entrée __default__
- Pour déterminer le contexte à utiliser, lit contexts/users/[seuser_id]. S'il n'est pas présent:

        - Recherche un contexte par défaut dans contexts/default_contexts. Si aucun contexte par défaut n'est trouvé, lit contexts/failsafe_context pour autoriser un contexte sûr.

   Noter que l'utilisateur system_u est définis dans ce fichier, cependant il ne doit pas y avoir d'utilisateur GNU/Linux system_u dans le système.

Fichiers booleans et booleans.local

   Dépréciés et généralement non présent, ces fichiers gèrent les booléens.

booleans.subs_dist

   Ce fichier, si présent, permet d'allouer de nouveaux noms de booléens dans la stratégie active. Ce fichier a été ajouté parce que beaucoup d'anciennes booléennes commençaient avec 'allow' qui rendait difficile à déterminer ce qu'ils faisaient. Par exemple allow_console_login et plus compréhensible avec login_console_enabled. Si ce fichier est présent, les 2 noms peuvent être utilisés. Chaque ligne est sous la forme policy_bool_name new_name.

setrans.conf

   Ce fichier est utilisé par mcstrands pour traduire les niveaux de stratégies MCS/MLS en labels user friendly.

secolor.conf

   secolor.conf contrôle la couleur associée avec les composant d'un contexte quand les informations sont affichées par SELinux par une application gérant les couleurs.

policy/policy.

   Fichier de stratégie binaire qui est chargé dans le kernel pour forcer la stratégie et est construit par checkpolicy ou semodule. Par convention l'extention du nom de fichier est la version de la base de stratégie utilisée pour construire la stratégie.

contexts/customizable_types

   Ce fichier contient une liste de types qui ne sont pas relabélisés par setfiles ou restorecon. Les commandes vérifient ce fichier avant de relabéliser et exclus ceux dans cette liste sauf si -F est utilisé.

contexts/default_contexts

   Ce fichier est utilisé par les application compatible SELinux pour définir un contexte de sécurité pour les processus utilisateurs (généralement les applications login) où l'identité de l'utilisateur GNU/Linux doit être connu par l'application.

contexts/dbus_contexts

   Ce fichier est pour le service de messagerie dbus qui est utilisé par certaines applications comme KDE. Si SELinux est activé, ce fichier doit exister pour que ces applications puissent fonctionner.

contexts/default_type

   Le fichier permet aux applications comme newrole de sélectionner un type par défaut pour un rôle si aucun n'est fournis.

contexts/failsafe_context

   Le fichier failsafe_context est utilisé quand un process login ne peut déterminer un contexte par défaut à utiliser. Le contenu du fichier est utilisé pour permettre à un administrateur d'accéder au système.

contexts/initrc_context

   Utilisé par la commande run_init pour permettre de démarrer les services système dans le même contexte de sécurité que init.

contexts/lxc_contexts

Ce fichier supporte le labéling des conteneurs lxc dans la librairie libvirt. Le format est le suivant:
process = "security_context"
file = "security_context"
content = "security_context"

process Une entrée qui contient le contexte de sécurité de domaine lxc
file contient le contexte de sécurité de fichier lxc
content Une entrée qui contient le contexte de sécurité de contenu lxc
sandbox_kvm_process
sandbox_lxc_process Ces entrées peuvent être présents

contexts/netfilter_contexts

   Ce fichier supporte le labeling Secmark pour netfilter/iptable. Il n'est pas utilisé actuellement.

contexts/removable_context

   Ce fichier contient un label par défaut pour les périphérique hot-plug qui ne sont pas définis dans contexts/files/media.

contexts/securetty_types

   Utilisé par newrole pour trouver le type à utiliser avec les périphériques tty en changeant les rôles ou niveaux.

contexts/sepgsql_contexts

   Ce fichier contient les contextes de sécurité par défaut pour les objets de base SE-PostgreSQL, décrit dans selabel_db

contexts/systemd_contexts

Ce fichier contient les contextes de fichiers utilisé par les tâches lancées via systemd. Le format est service_class = security_context.Exemple:
runtime=system_u:object_r:systemd_runtime_unit_file_t:s0

contexts/userhelper_context

   Ce fichier contient le contexte de sécurité par défaut utilisé par les applications system-config-*, lancés en root.

contexts/virtual_domain_context

   Ce fichier est utilisé par libvirt et fournis les contextes de domaine qemu disponibles dans la stratégie. Il peut y avoir 2 entrées dans ce fichier, la deuxième étant un contexte alternatif.

contexts/virtual_image_context

   Ce fichier est utilisé par libvirt et fournis les contextes d'image qui sont disponibles dans la stratégie. La première entrée est le contexte de fichier image et la seconde est le contexte du contenu de l'image.

contexts/x_contexts

   Ce fichier fournis les contextes de sécurité par défaut pour l'extension de sécurité SELinux, décris dans selabel_x.

contexts/files/file_contexts

   Ce fichier est géré par semodule et semanage et ne devrait pas être édités. Ce fichier est utilisé par des commandes comme setfiles, fixfiles, matchpathcon, restorecon pour relabéliser parties ou tout un système de fichier.

contexts/files/file_contexts.local

   Ce fichier est géré par semanage fcontext.

contexts/files/file_contexts.homedirs

   Ce fichier est géré par semodule et semanage et ne devrait pas être édité. Il est généré par genhomedircon et utilisé pour définir les contextes de sécurité dans les répertoires personnels.

contexts/files/file_contexts.subs[_dist]

   Ces fichiers permettent des substitutions de noms de fichier pour les fonctions matchpatchcon(3) et selabel_lookup(3).

contexts/files/media

   Ce fichier est utilisé pour mapper les types de média en un contexte de fichier.

contexts/users/[seuser_id]

   Ces fichiers optionnels sont nommés d'après les utilisateurs SELinux qu'ils représentent. Chaque fichier est utilisé pour assigner le contexte de sécurité correct à l'utilisateur, généralement durant le login.

logins/

   Ces fichier optionnels sont utilisés par les application de login pour obtenir un username SELinux et un niveau basé sur l'UID GNU/Linux et le nom du service.

users/local.users

   Généralement le fichier local.users n'est pas présent si semanage est utilisé pour gérer les utilisateurs. Ce fichier contient les définitions des utilisateurs locaux sous la forme de déclarations user.

Langage de stratégie SELinux

   Cette section est une référence des déclarations règles de langage de stratégie.

Langage de stratégie kernel

   Il y a 3 types de base de fichier source de stratégie qui peuvent contenir des déclarations et règle de langage. Ces 3 type sont:

monolitique Simple fichier source qui contient toutes les déclarations. Par convention, il est appelé policy.conf et est compilé par checkpolicy.
base Fichier source obligatoire qui supporte l'infrastructure modulaire. Toute la stratégie système peut être contenu dans ce fichier, cependant il est plus courant d'avoir des fichiers sources de modules chargeable séparés. Par convention ce fichier est appelé base.conf
module Ces fichiers sources optionnels peuvent être chargés dynamiquement dans le magasin de stratégie. Par convention ces fichiers sont nommés d'après le module qu'ils représentent.

   Le tableau ci-dessous affiche l'ordre dans lequel les déclarations devraient apparaître dans les fichiers sources

Déclarations de base et modules
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
^
24 mars 2017

htmlpdflatexmanmd




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