Application à GRSECURITY

Comme SELinux, GRSECURITYest une implantation de contrôle d’accès obligatoire. GRSECU -RITYimplante une version allégée des modèles RBAC etDTE. Dans cette partie, nous étudions tout d’abord la syntaxe du langage d’expressions de politiqueGRSECURITY. Puis, nous montrerons com-ment notre outil projette une politiqueGRSECURITYen une politique neutre. Une description deGR

-SECURITYest proposé dans l’annexe D.2 (page 198).

6.1.3.1 Politique cibleGRSECURITY

Le listing 6.4 contient un exemple de politique cible GRSECURITY. Les lignes 1 à 5 définissent les règles associées au rôle system_r (déclaré à la ligne 1). Une déclaration de rôle débute par le mot clé role, suivie du nom du rôle puis d’un ensemble d’attributs. Cette déclaration est valide jusqu’à la prochaine déclaration de rôle et permet de définir toutes les règles associées à ce rôle. Les lignes commençant par subject correspondent aux règles d’accès, qui ont pour contexte sujet

6.1. CONVERSION D’UNE POLITIQUE EN LANGAGE NEUTRE 153

✞ ☎

1 role system_r G

2 role_transitions user_r, admin_r 3 subject / usr / bin / httpd

4 / var / www rwe 5 / etc / apache2 r 6 [ . . . ]

✡^{✝ ✆}

Listing 6.4 – Extrait de configuration grsecurity.

le programme qui suit le mot-clé subject, et pour contexte objet chacune des lignes suivantes, jusqu’au prochain mot-clé subject. Par exemple, la ligne 5 définit un accès en lecture (r) entre le processus /usr/bin/httpd et les fichiers contenus dans le répertoire /etc/apache2. Cette règle concerne le rôle englobant system_r.

Les lignes débutants par role_transitions définissent les changements de contextes légaux. Par exemple, la ligne 2 autorise le contexte ayant le rôle system_r à transiter vers le rôle user_r ou admin_r .

6.1.3.2 Projection en langage neutre

Comme pour SELinux, la projection d’une politique GRSECURITY se fait par énumération des contextes et des vecteurs d’interactions. Ces vecteurs sont ensuite traduits en XML afin d’obtenir une politique neutre. Dans cette partie, nous détaillons donc comment énumérer les contextes et les vecteurs d’interactions d’une politiqueGRSECURITY.

A) Énumération des contextes de sécurité GRSECURITY ne définit pas les contextes de sécurité de la même façon que SELinux. GRSECURITY désigne les contextes par leur chemin dans le sys-tème de fichier. Pour comparaison, SELinux désigne le processus du serveur Apache par le contexte (system_u, system_r, httpd_d)etGRSECURITYle désigne simplement par le chemin du fichier exécutable d’Apache, soit /usr/bin/httpd. L’avantage pourGRSECURITYest que la dési-gnation des contextes est directe. Cependant, comme les contextes de sécurité permettent des classes d’équivalence dans SELinux, il faudra davantage de règles dans GRSECURITY pour écrire une poli-tique équivalente à celle de SELinux.

De ce fait, nous avons besoin d’un mécanisme pour traduire les chemins en contextes sujets ou objets. Pour cela nous proposons une solution de traduction des contextesGRSECURITYen contextes neutres.

a) Énumération des contextes objets Nous utilisons le fichier SELinux file_contexts (cf. listing 6.3) pour donner la correspondance entre un contexteGRSECURITY(chemin) et un contexte neutre (le triplet u:r:t inclut dans le fichier file_contexts). Si nous prenons la troisième ligne de la politique 6.4, le chemin correspond à /var/www. Dans le fichier file_contexts du lis-ting 6.3, la ligne 1 correspond à /var/www et donne le contexte neutre system_u:object_r: var_www_t. Cette méthode permet ainsi d’énumérer l’ensemble des contextes objets de notre poli-tique neutre.

b) Énumération des contextes sujets Pour énumérer les sujets, nous réutilisons les fichiers de configuration de SELinux : file_contexts et policy.conf. Le fichier policy.conf per-met d’énumérer tous les types exécutables (qui possèdent l’attribut file_exec). Cette énumération

permet d’obtenir, via le fichier file_contexts, tous les chemins associés à ces types. Finalement, le fichier policy.conf permet d’obtenir le type sujet (domaine) associé aux types exécutables. Ainsi, nous obtenons une association (chemin, type sujet). Toutes ces associations sont stockées dans le fichier sc_contexts, tel que l’illustre le listing 6.5. Dans ce listing, chaque ligne définit un che-min et le type sujet associé. L’énumération des contextes de sécurité sujets se fait alors de la manière

✞ ☎

/ usr / sbin / httpd httpd_d / usr / sbin / ssh ssh_d / usr / bin / login login_d

[ . . . ]

✡^{✝ ✆}

Listing 6.5 – Tablesc_contextsde correspondance entre chemins et types sujets..

suivante :

– Pour chaque chemin, on extrait le type t qui lui est associé (avec la table sc_contexts) ; – Pour chaque rôle r accédant à ce chemin (cf. listing 6.4), on énumère les utilisateurs u accédant

à ce rôle (via le fichier SELinux seusers) afin d’obtenir tous les contextes sujet u:r:t correspondant à ce chemin.

Cette méthode permet ainsi d’énumérer l’ensemble des contextes sujets d’une politique neutre. Par exemple, le listing 6.4 déclare le sujet /usr/bin/httpd, qui correspond au type httpd_d d’après la table sc_contexts. Ce sujet est déclaré dans rôle system_r, si l’utilisateur system_u peut accéder à ce rôle (cf. fichier seusers), nous obtenons alors le contexte : system_u:system_r: httpd_d.

B) Énumération des vecteurs d’interactions Le format des règles d’accès deGRSECURITY est simple (cf. listing 6.4) : on trouve une première ligne commençant par subject déclarant un chemin sujet, les lignes suivantes désignent les chemins objets et les permissions d’accès. Afin de convertir ces permissions sous forme neutre, nous utilisons une table de traduction. Le listing 6.6 contient un extrait de cette table.

✞ ☎ r file : read w file : write x file : execute [ . . . ] ✡^{✝ ✆}

Listing 6.6 – Extrait de la table de traduction des permissionsGRSECURITYen opérations neutres. La conversion d’une règleGRSECURITYen un vecteur neutre est réalisée de la manière suivante : – Les permissionsGRSECURITYsont traduites en forme neutre via la table de traduction 6.6 ; – Les sujetsGRSECURITYsont traduits en forme neutre via l’énumération des sujets ;

– Les objetsGRSECURITYsont traduits en forme neutre via l’énumération des objets.

Par exemple, les permissions de la ligne 4 sont converties en l’ensemble is = {file : read, write, execute}. Le sujet et l’objetGRSECURITYsont convertis en forme neutre system_u: system_r:httpd_det system_u:object_r:var_www_t par les méthodes d’énumérations précédentes. Nous obtenons donc le vecteur : (system_u:system_r:httpd_d, system_u :object_r:var_www_t, { file:read, write, execute }). Ce vecteur est alors traduit enXML:

6.1. CONVERSION D’UNE POLITIQUE EN LANGAGE NEUTRE 155

Nom GR 1 GR 2 GR 3 GR 4

Description Distribution Gentoo Défaut Fedora Fedora Type Serveur/Utilisateur Serveur Serveur Serveur Installation Complète Minimale Standard Standard

Sujet 201 21 18 21

Politique Rôle 19 2 9 13

Cible Règle 6563 81 509 925

Temps 1min33s 6s 9s 14s

Contexte objet 104 34 44 46

Politique Contexte sujet 104 5 16 24

Neutre Contexte 208 39 60 70

Vecteur 1399 89 206 318

TAB. 6.2 – Exemple de conversion de politiqueGRSECURITY

✞ ☎

<access_rule>

< s u b j e c t > ( system_u , system_r , httpd_d ) < / s u b j e c t > < o b j e c t > ( system_u , object_r , var_www_t ) < / o b j e c t > < p e r m _ l i s t >

<perm>{file : read , write , execute}< / perm> < / p e r m _ l i s t >

< / access_rule>

✡^{✝ ✆}

En appliquant cette méthode sur l’ensemble de la politiqueGRSECURITY, nous obtenons la politique neutre au formatXML.

6.1.3.3 Exemples de conversion

Nous avons écrit un outil (en shell-script) qui permet de convertir une politique au formatGRSE

-CURITYen politique neutre. Nous avons appliqué cet outil sur quatre politiquesGRSECURITY

prove-nant de quatre machines différentes. La table 6.2 contient une synthèse des résultats obtenus lors de l’utilisation de cet outil. Nous considérons ainsi quatre politiques :

– GR 1 est une politique qui provient d’une machine contenant des applications serveurs (serveur Web, mail, etc.) et utilisateurs (environnement X, outils de développement, etc.) ;

– GR 2 est la politique livrée avecGRSECURITY; – GR 3 est la politique d’un serveur mail ; – GR 4 est la politique d’un serveur Web et DNS.

Les politiques 1, 3 et 4 ont été obtenues avec la phase d’apprentissage deGRSECURITY, la politique 2 a été définie manuellement par le créateur deGRSECURITY.

Une politique standard (GR 3 et 4) définit en moyenne 20 sujets, 10 rôles et moins de 1000 règles de contrôle d’accès. Notre exemple de politique complexe (GR 1) définit 201 sujets (un par application) pour 19 rôles et contient 6563 règles de contrôle d’accès. Finalement, la politique livrée

avec GRSECURITY (GR 2) définit 21 sujets et 2 rôles (administrateur et utilisateur) pour un total de

81 règles.

Pour effectuer la conversion du langage de GRSECURITY vers notre langage neutre, notre outil nécessite quelques secondes pour une politique standard à quelques minutes pour une politique com-plexe. La politique neutre résultante contient ainsi moins de 100 contextes pour une politique standard à plus de 200 pour une politique complexe.

6.1.4 Discussion

Nous pouvons tout d’abord remarquer qu’une politiqueGRSECURITY définit beaucoup moins de règles qu’une politique SELinux. Ceci vient du fait qu’une politique GRSECURITY est obtenue par apprentissage alors qu’une politique SELinux est générique. Elle est donc plus complète et adaptée à un parc de machines. Une politique SELinux contient des règles qui ne sont pas nécessairement utiles à chaque machine.

De plus, SELinux comprend un ensemble d’opérations élémentaires beaucoup plus important que

GRSECURITY (500 contre 10). SELinux permet ainsi de contrôler plus finement les appels système

que GRSECURITY. En contrepartie, une politique SELinux nécessite la définition de beaucoup de

règles et elle est donc beaucoup plus complexe à définir.

Les conversions, présentées dans cette section, ont été obtenues sur une machine de bureau équipée d’un processeur à 3Ghz et de 2Go de mémoire vive. Étant donné que cette phase de conversion n’est nécessaire que lorsque la politique de contrôle d’accès est modifiée, ces expérimentations montrent que les temps de calcul sont raisonnables et que cette phase peut être réalisée aisément.

Dans les sections suivantes, nous détaillons le fonctionnement de l’outil, nomméPIGA, qui im-plante la solution de détection définie dans le chapitre 5 (page 127) et met donc en œuvre les trois phases définies : 1) construction des graphes, 2) génération de la base de signatures, et 3) détection des activités illicites.