Exemple - Contrôle d'accès par les ontologies : Outil de validation automatique des droits d'ac

3.5.1 Traduction de droits d’accès Linux vers XACML

Avant de donner un exemple de traduction d’un droit d’accès Linux vers XACML, commençons par une explication de la représentation des droits d’accès Linux.

Représentation des droits d’accès sous Linux

Les concepts de base pour le contrôle d’accès dans Linux

Dans les systèmes d’exploitation Linux, le contrôle d’accès se fait en suivant le modèle DAC. En effet un objet (fichiers, processus d’exécutions) appartient à un propriétaire dit Owner et

Figure 3.2: linux strcture basic des droits d’accès

est également associé à un Groupe dit Owner Group. Le reste des utilisateurs dit Others sont pris en compte dans la définition des droits d’accès sur un objet.

À l’exception du super-utilisateur qui a un contrôle total sur tous les objets du système, seul le Owner peut lire, écrire ou exécuter ses objets ; et seul lui peut donner des accès au Owner Group et aux Others. Plus de détails sur le contrôle des droits d’accès sur Linux se trouvent dans [27].

Les droits d’accès attribués à un objet sont représentés par trois jeux de trois caractères qui appartiennent à l’ensemble : {r, w, x, −}. Le premier des jeux de trois caractères, désigne le droit d’accès du Owner, le second jeu de trois caractères représente les droits d’accès du Owner Group et dernier jeu de caractères désigne les droits attribuer au Others comme le montre la figure3.2. Ainsi on obtient trois blocs de trois caractères. Le premier caractère de chaque bloc donne le droit de lecture si sa valeur est égale à "r", sinon sa valeur est égale à "−" et l’accès en lecture n’est pas autorisé. Le second caractère de chaque bloc indique le droit d’accès en écriture sur un objet ; si sa valeur est égale à "w" alors l’accès en écriture sur un objet est autorisé ; sinon la valeur est égale à "−". Le troisième caractère d’un bloc désigne l’autorisation d’exécuter un objet si la valeur du caractère est égale à "e" et de refuser l’exécution de l’objet si la valeur est "−". La structure minimale de l’attribution des droits d’accès sur un objet est mise en exergue sur la figure3.4.

En effectuant la commande ls -l , on peut retrouver les droits d’accès des différents fichiers comme le montre la figure3.3.

Figure 3.3: Droit d’accès Linux : Example

Dans cet exemple, le premier caractère indique le type de l’objet (− pour un fichier normal, dpour un répertoire, l pour un lien symbolique, b pour un bloc disque et c un caractère d’un équipement). Les caractères suivants donnent les droits d’accès pour respectivement le Owner, Owner Group et Others. La valeur -rw-r–r-– indique que le Owner a les droits de lecture et d’écriture, le Owner Group et le Others ont le droit de lecture. Sous Linux, les droits d’accès peuvent être modifiés par le Owner où le super-utilisateurs en utilisant la commande chmod.

Gestion des listes de contrôles d’accès sous Linux

Durant les dernières années, plusieurs versions récentes de système Unix-Like ont été patchées pour intégrer les ACLs (Access Control List) [27] qui permet d’implémenter le modèle manda- taire (MAC). Cette extension permet de rendre plus flexible et plus fine la gestion des droits d’accès. Les ACLs ne remplacent pas le modèle standard de Linux, mais font une extension et garantis la rétrocompatibilité.

Les ACLs peuvent être divisés en deux groupes :

• l’ACL minimal, voir la figure3.4, représente le modèle traditionnel du contrôle d’accès Linux.

Figure 3.4: ACL Minimale

• L’ACL étendue, voir figure 3.5, introduit la notion de masque (Mask), d’utilisateurs nommés (Named User) et de groupes nommés (Named Groups). Ainsi, il vient enrichir les ACL minimales. Les droits d’accès concernant le Owner et Others restent effectives. Cependant, pour les autres entrées (Named User, Named Groups, et Named User et Owner Groups) les droits d’accès sont attribués s’ils sont également attribués au masque, sinon, leurs droits sont considérés comme étant masqués.

Figure 3.5: ACL Etendue

Il n’est pas difficile de comprendre le rôle des utilisateurs nommés et des Groupes nommés qui vont nous permettre d’attribuer individuellement des droits à, respectivement, des utilisateurs

et des groupes.

Les commandes Linux getfacl et setfacl permettent de visualiser et de modifier les ACLs. Exemple : Prenons le fichier exemple.txt avec les droits d’accès −rw − − − − − −˘ pour l’utilisateur lionel appartenant au groupe "users". Si l’utilisateur courant nommé test appartenant au groupe test veut lire le fichier exemple.txt, cela va se traduire par un échec. La capture du Shell Linux suivant le confirme.

#id uid=1003(test) gid=1000(test) #ls -l exemple.txt -rw--- 1 lionel users 6492 2004-12-29 19:36 exemple.txt # cat exemple.txt

cat: exemple.txt: Permission denied

l’execution de la commande getfacl donne : # getfacl exemple.txt file: exemple.txt owner: lionel group: users user::rw- group::--- other::---

Nous pouvons remarquer que seul l’utilisateur lionel a des droits d’accès sur le fichier, le reste des utilisateurs n’a aucun droit sur le fichier exemple.txt. Cependant grâce au ACL étendu, il est possible de donner l’accès en lecture et en écriture à l’utilisateur test. Pour ce faire, on utilise la commande setfacl. Ainsi dans un shell on obtien :

# setfacl -m user:test:rw exemple.txt # ls -la exemple.txt -rw-rw----+ 1 lionel users 6492 2004-12-29 19:36 exemple.txt # getfacl exemple.txt ... user::rw- user:test:rw- group::--- mask::rw- other::---

Ainsi, avec le masque rw− qui est identique pour l’utilisateur test membre du groupe users il est possible de de lire et d’écrire le fichier exemple.txt.

SELinux

SELinux est un module de sécurité introduite dans la famille des systèmes d’exploitation Linux pour implémenter le modelé de contrôle d’accès RBAC dans la gestion des droits d’accès Linux. Ainsi, il permet de définir des niveaux de sécurité pour classer les applications du système. Ce procédé augmente la finesse du contrôle d’accès, car dans Selinux, on attribue un niveau de confidentialité pour chaque objet du système. Les différentes entités de SeLinux sont :

– Les Types. Le type est l’attribut le plus important pour un objet, car les décisions d’accès se basent sur le type de l’objet source et le type de l’objet cible à accéder. Le type est un attribut que l’on assigne à un objet (fichier, port réseau, etc.) et un processus ; dans ce cas, on parle de domaine au lieu de type. La présence du suffixe _t désigne un type : Exemple sysadm_t.

– Les Roles. Dans SELinux, la notion de rôle est différente de la notion de rôle dans RBAC. En effet, le rôle est un intermédiaire entre un utilisateur et un type ou un domaine. Le rôle décrit un ensemble de types qu’un utilisateur peut utiliser. D’une manière générale, le rôle est identifié par le suffixe _r.

Exemple : soit un administrateur qui utilise un système pour faire une tache qui est dans le rôle staf_r ; s’il veut faire des taches d’administration système, il doit explicitement entrer dans le rôle sysadm_r.

– Les Identités. Les identités sont similaires à la notion de nom d’utilisateur dans Linux (username). À chaque identité SELinux, on attribue un ensemble de rôles. En général, l’identité d’un utilisateur ne change pas durant une session. Dans SELinux, il existe des identités génériques qui peuvent être attribuées à chaque utilisateur. Ainsi, tout utilisateur Linux est mappé à un utilisateur SELinux par la politique actuelle. Ce mappage permet l’héritage des droits et restrictions de l’utilisateur SELinux correspondant. – Le contexte. Dans SELinux, le contexte est très important dans le mécanisme d’attri-

bution ou refus d’accès sur un objet. Un contexte SELinux est présenté de la manière suivante : identite : role : type. La commande ls − Z permet de visualiser les contextes. Exemple :

# ls -Z

drwxr-xr-x root root system_u:object_r:bin_t bin drwxr-xr-x root root system_u:object_r:boot_t boot drwxr-xr-x root root system_u:object_r:device_t dev drwxr-xr-x root root system_u:object_r:etc_t etc

On remarque que le rôle générique object_r est attribué à tous les objets. Les autres champs du contexte nous permettent de déduire que les fichiers qui ont la même identité system_u et ont des types différents : bin_t, boot_t, device_t et etc_t.

Chaque objet (ou processus) est confiné à son propre type (ou domaine), et ne pourra pas accéder à des informations qui ne sont pas placées dans le bon contexte. Il est possible de connaître la liste des contextes à laquelle peut accéder un processus à l’aide de la commande sesearch.

Traduction en XACML

Dans une machine qui tourne sur Linux, la représentation des droits d’accès peut être visualisée en lançant la commande "ls -l". Cela nous donne un ensemble d’information sur les permissions d’accès et la propriété d’un objet du système d’exploitation. Exemple :

-rw-r--r-- 1 root staff 0 18 fv 20:19 exemple.txt

on peut extraire les droits d’accès suivant :

U tilisateur Actionpermise Actionnonpermise

root rw x

staf f r wx

any r wx

En utilisant XACML pour représenter cet objet de droits d’accès Linux, on va s’accorder sur les règles suivant :

– l’utilisation de l’algorithme de combinaison fist − applicable

– chaque action permise et action non permise est transformé en une règle XACML avec ses attributs appropriés de subject, resource et action.

hf irst − applicable;

target : {string − equal(“exemple.txt00, resource.resource − id)}; rules : {(deny; target : {

string − equal(root, subject.subject.id) ustring − equal(”x”, action.action − id)}) (permt; target : {

string − equal(root, subject.subject.id) ustring − equal(”rw”, action.action − id)}) (deny; target : {

string − equal(staf f, subject.subject.id) ustring − equal(”w”, action.action − id) ∨string − equal(“x00_{, action.action − id)})}

(deny; target : {

string − equal(”w”, action.action − id) ∨string − equal(”x”, action.action − id)}) (permit; target : {

string − equal(”r”, action.action − id)})}i On peut voir le document XACML complet en annexeA.1.

3.5.2 Traduction de droits d’accès Windows vers XACML

Pour comprendre l’exemple de traduction des droits d’accès Windows vers XACM, nous allons faire une petite description de la représentation de contrôle d’accès sous Windows.

Le contrôle d’accès sous Windows

Windows est un système d’exploitation qui implémente le modèle de contrôle d’accès discré- tionnaire. D’une manière basique, les systèmes Windows utilisent des listes de contrôle d’accès discrétionnaire (DACL : discretionary access control lists) pour renforcer le contrôle des droits d’accès sur ces différents objets. Ainsi, l’accès à tout objet (fichier, dossier dans NTFS, objet Active Directory, clé de registre, etc.) peut être contrôlé par un descripteur de sécurité. Il existe également la notion de sujet dans les systèmes Windows qui sont composés d’utilisateurs, processus, ordinateurs, etc. Ces sujets sont appelés Principal Security dans le modèle de Microsoft et sont identifiables grâce à un SID (Security identifier).

Dans la figure3.6, le descripteur de sécurité [28] est constitué :

– d’un entête qui contient les informations sur la version du descripteur et les adresses qui fournissent les positions des DACL et SACL ;

– d’un SID du propriétaire de l’objet (Owner SID) ;

– d’un DACL qui décrit les droits d’accès pour les utilisateurs et les groupes ; – et d’un SACL qui permet de contrôler comment l’accès est effectué.

Figure 3.6: Structure d’un descripteur de sécurité

Un DACL est une liste de plusieurs ACE (Access Control Entries). Tous les ACEs fournissent les informations de contrôle d’accès suivant :

– Un SID qui identifie un utilisateur ou un groupe ;

– Un masque d’accès de 32-bite qui spécifie le droit d’accès. Chaque bit correspond à un droit d’accès spécifique qui dépend du type d’ACE et qui peut prendre la valeur 1 ou 0. – Un ensemble de bits flags qui détermine si les objets fils peuvent hériter de l’ACE. – Un flag qui indique le type de l’ACE [29].

À titre d’exemple, si le bit correspondant au droit d’accès lire une permission a la valeur 1 et le type de l’ACE est Deny, l’ACE interdit le droit de lire les permissions de l’objet. Si le même bit est à 1 et que le type de l’ACE est Allow, ACE autorise la lecture des permissions de l’objet.

[30] Le format du masque d’accès est composé de bits qui correspondent aux types de droits d’accès suivant :

– les droits génériques qui facilitent la portabilité des applications. Exemple : generic read, generic write, generic execute, generic all ;

– les droits standards qui s’appliquent à n’importe quel type d’objet. Exemple : DELETE (droit de supprimer l’object), WRITE DAC (droit de moditier le DACL), WRITE OW- NER (droit de changer le propriertaire de l’objet) ;

– les droits spécifiques qui dépendent du type d’objet. Exemple : Traverse Folder/ Execute File (Pour un dossier : Traverse Folder autorise ou interdit la navigation à traverser le dossier pour chercher des fichiers ou des dossiers. Pour un fichier : Execute File autorise ou interdit l’exécution du fichier).

Figure 3.7: Example 1

Le propriétaire d’un objet n’a pas nécessairement une entrée dans le DACL, mais peut, impli- citement, lire et modifier les permissions de son objet.

Si un objet ne possède pas de DACL, le système Windows autorise l’accès total à tous les utilisateurs ; sinon, le système vérifie les ACE qui sont dans le DACL de l’objet. Chaque ACE d’un DACL d’un objet spécifie le droit d’accès permis ou refusé pour l’utilisateur qui peut être un simple utilisateur, un groupe ou une session de connexion. [31]

Le système examine chaque ACE séquentiellement jusqu’à trouver un événement parmi les suivants :

– Un refus d’accès : l’ACE refuse explicitement l’accès à toute requête initiant une demande d’accès listé. Voir Figure 3.8.

– Un ou plusieurs accès autorisés par les ACEs ; dans ce cas, les droits d’accès sont accordés à toute requête initiant une demande d’accès. Voir Figure 3.7.

– Tous les ACEs ont été vérifiés et jusqu’au dernier, les ACEs ne donnent pas une réponse explicite d’autorisation. Dans ce cas les droits d’accès sont simplement refusés. [30] Dans Microsolft Windows, le SDDL (Security descriptor definition language) est le langage utilisé pour définir un format de chaine de caractère pour convertir le descripteur de sécurité en texte comme on peut le voir dans les figures3.9et3.10.

Traduction vers XACML

Comme nous l’avons fait avec XACML, nous avons besoin d’une grammaire BNF pour le SDDL. Ainsi, dans le tableau3.2, on définit la syntaxe de SDDL.

Figure 3.8: Example 2

Figure 3.9: Language SDDL

Security Descriptor ::= { Owner_SID ; Goup_SID ; DACL} DACL ::= {Dacl-flag, ACE}

ACE ::= {ACE Type ;ACE Flag ; Rights ;SID } DACL ::= hace :{Ace}i

ACE Type ::= A | D ACE Flag ::= CI | OI | NP IO | ID | SA | FA Rights ::= GA | GR | GW | GX | . . . SID ::= S-1-5-21domaine-500 | S-1-1-0 DACL Flag ::= P | AR | AI | AU | SY | . . . Owner_SID ::= S-1-5-21domaine-500 | . . . Group_SID ::= BA | . . . Table 3.2: SDDL Syntax Windows XACML

Security Descriptor =⇒ Policies

ACE =⇒ Rules

Rights, SID =⇒ Targets

ACE :Type =⇒ Effect

Ralg= first-applicable

Table 3.3: Traduction de SDDL vers XACML

En utilisant la syntaxe SDDL, on peut alors définir le tableau3.3comme table de correspon- dance entre SDDL et XACML.

Après ces deux étapes, on peut donner l’exemple de traduction d’un droit d’accès Windows vers XACML. Ainsi, soit le SDDL du fichier test.txt suivant :

O:S-1-5-21-718938447-1703640164-3469265397-1000 G:S-1-5-21-718938447-1703640164-3469265397-513

D:AI(D;;CC;;;\S-1-5-21-718938447-1703640164-3469265397-1001) (A;ID;FA;;;BA)

En applicable règle de transformations de SDDL vers XACML on obtient : hf irst − applicable;

target : {string − equal(”text.txt”,

resource.resource − id)};

rules : {(deny; target : {

string − equal(”S − 1 − 5 − 21 − 718938447 −1703640164 − 3469265397 − 1001”, subject.subject.id)

ustring − equal(”CC”, action.action − id)}) (permit; target : {

string − equal(”BA”, subject.subject.id) ustring − equal(”F A”, action.action − id)}) (permit; target : {

string − equal(”S − 1 − 5 − 21 − 718938447 −1703640164 − 3469265397 − 1000”, subject.subject.id)

ustring − equal(”GA”, action.action − id)})}i On peut voir le document XACML complet en annexe A.2.

3.5.3 Outil de validation

Comme le montre la fugure 3.11, l’outil de validation se divise en plusieurs partie :

1. Chargeur de fichier XACML pour récupérer les droits d’accès à analyser à partir d’un fichier XACML existant.

2. Outil de scan réseau pour faire une découverte réseau et cibler les postes sur lesquels on peut récupérer les droits d’accès. Cela fait appel, en arrière-plan, aux outils de provi- sionning.

3. La liste des machines dont les droits d’accès seront analysés et donc les droits d’accès qui ont été recueillis.

4. La liste des objets à instancier dans l’ontologie pour chaque machine. 5. Les boutons de traitement pour débuter la validation.

Cette première fenêtre permet de faire l’instanciation de l’ontologie. Une fois cette étape passée, nous accédons à l’interface suivant qui est décrit dans la figure 3.12 où va se faire la validation et les différentes opérations d’interrogation de l’ontologie.

Dans le document Contrôle d'accès par les ontologies : Outil de validation automatique des droits d'accès (Page 68-79)