Étude de NSA Security Enhanced Linux : SELinux

Étude de NSA Security Enhanced Linux : SELinux

Université Henri Poincaré - Nancy I Isial: Institut Supérieur d’Informatique de d’Automatique de Lorraine Diplôme d’Études Supérieures Spécialisées d’Infomatique Second projet de l’option Responsable Tronc Commun : Nacer BOUDJLIDA Responsable option Ingénierie des Réseaux et des Systèmes : Bernard MANGEOL Étude de NSA Security Enhanced Linux : SELinux Mathieu BAEUMLER, David HOEUNG et Laurent VALLAR, Nancy, le 29 mars 2004

TABLE DES MATIÈRES 1 Table des matières 1 introduction 2 1.1 presentation . 2 1.2 historique . 3 2 Linux Security Modules 4 2.1 Contrôle d’accès . 4 2.1.1 Modèle de sécurité . 4 2.1.2 Politiques et mécanismes . 4 2.2 Architecture des LSM . 7 2.2.1 Points de contrôle . 7 2.2.2 Champs de sécurité . 9 2.2.3 Communication avec l’espace utilisateur . 12 2.2.4 Tests de consistance . 13 2.2.5 Enregistrement et empilage des LSM . 16 3 Architecture de SELinux 20 3.1 Mandatory Acces Control . 20 3.2 Le modèle Flask . 20 3.3 Modèles de sécurité . 21 3.3.1 Type Enforcement . 21 3.3.2 Role-Based Access Control . 22 3.3.3 Multi-Level Security . 23 3.3.4 Labeled Networking Support . 23 4 Intégration de SELinux 24 4.1 dans le noyau . 24 4.2 dans les démons et utilitaires . 24 5 Etude de la mise en œuvre sur Mandrake 25 5.1 Contexte . 25 5.2 Objectifs . 25 5.3 Contraintes . 25 5.4 Réalisation . 26 5.5 Problèmes rencontrés . 27 5.5.1 sur le noyau . 27 5.5.2 sur la distribution . 28 5.5.3 sur le contexte . 29 5.5.4 complexité de la mise œuvre . 30 5.6 Solutions préconisées . 30 6 Conclusion 32 Table des figures 33 Bibliographie 34

1 INTRODUCTION 2 1 Introduction 1.1 Présentation SELinux (Security Enhanced Linux) est une solution de sécurité offrant un blindage du noyau Linux, en lui apportant des fonctionnalités de protection poussées supplémentaires comme, en autre, le MAC (Mandatory Access Control), que nous allons détailler plus loin. Ce projet est une initiative américaine et a été lancé par la NSA (National Security Agency), assez connue du grand public depuis les révélations concernant le projet Eche- lon, réseau planétaire de surveillance et d’interception de communications. La première mouture publique de SELinux a été donnée à la communauté du Logiciel Libre (sous licence GPL) vers la fin 2000 par l’Information Assurance Research Office qui pilote le projet. Cette entité de la NSA demeure responsable de la recherche et du dé- veloppement de solutions de sécurité dans le domaine des technologies de l’information, pour des infrastructures sensibles avec une vocation gouvernementale et industrielle... Nous commencerons par introduire l’architecture globale de SELinux (Flask...) et son intégration au noyau existant via les LSM (Linux Security Modules), pour ensuite détailler son fonctionnement interne et ce qui façonne ses atouts (principalement TE et RBAC qui seront présentés plus loin) avant de détailler l’ensemble des problèmes rencontrés dans le cadre restreint de l’ installation d’une passerelle d’accès sécurisée sous distribu- tion Mandrake pour le Loria (Laboratoire lOrrain de Recherche en Informatique et ses Applications).

Mais, avant de débuter la partie purement technique, nous allons faire un bref rappel de l’historique de l’entrée de SELinux dans l’univers de la communauté Linux.

1 INTRODUCTION 3 1.2 Historique Lors du Kernel Summit de San Jose, en mars 2001, Peter Loscocco présenta Security Enhanced Linux (SELinux), un patch pour le noyau Linux implémentant une architecture de contrôle d’accès, tous deux développés par la NSA. SELinux n’était pas le seul correctif de la sorte, D’autres projets comme RSBAC, Me- dusa DS9, LIDS, SubDomain, DTE ou encore LoMAC [rsbac, medusa, lids, subdomain, dte, lomac] implémentent d’autres contrôles d’accès ou d’autres charpentes de contrôle d’accès.

Linus Torvalds, conscient de la nécessité de permettre d’autres types de contrôles d’accès en standard, autres que ceux déjà présents1, et plutôt que de privilégier un type de contrôle d’accès sur tous les autres, décida alors qu’il serait prêt à intégrer dans la distribution standard du noyau 2.6 une charpente commune laissant à chacun le choix de sa méthode de contrôle d’accès.

Ainsi naquit le projet Linux Security Modules (LSM). La charpente prit la forme d’un ensemble de points de contrôle (hooks ou ancres) dans le noyau Linux, afin de brancher les différents type de contrôles d’accès. On y trouve actuellement une implémentation de SELinux , LIDS, DTE, et même les capabilities ont été sorties du noyau pour s’appuyer sur le projet LSM. Il est à noter que le mot module dans les LSM ne signifie pas que le contrôle d’accès doit être implémenté sous forme de module noyau (LKM), mais que la charpente est assez bien faite pour que tout code de contrôle d’accès l’utilisant soit modulaire. On peut ainsi le compiler sous forme de module si on le désire, mais rien ne nous y oblige.

1C’est à dire le Discretionary Access Control : DAC, les droits UNIX que tout le monde connaît, avec en plus les capabilities

2 LINUX SECURITY MODULES 4 2 Linux Security Modules 2.1 Contrôle d’accès Lorsque l’on souhaite sécuriser un système, il est indispensable de mettre en place un mécanisme de contrôle d’accès. Ce mécanisme doit décider si une requête doit être acceptée ou si elle doit être rejetée... 2.1.1 Modèle de sécurité Pour pouvoir prendre les décisions de contrôle d’accès, il faut déterminer QUI peut ACCÉDER à QUOI.

– Qui : Un sujet est une entité agissant sur le système (exemple : un processus agissant pour le compte d’un utilisateur). – Quoi : Un objet est une entité passive du système (exemple : un fichier). On peut noter que dans un système, un élément peut-être à la fois sujet et objet, par exemple l’utilisateur qui appelle su est un sujet, mais l’identité est un objet. – Contrôle d’accès : Le contrôle d’accès est effectué à partir des privilèges, per- missions, ou droits de l’utilisateur (exemple : Sous unix les droits sont Read, Write, eXecute).

– Authentification : L’authentfication est de garantir l’identité du sujet (mot de passe, smartcard, biométrie). Elle permet ensuite de confronter la requête aux permissions. – Audit : L’audit est le mécanisme de supervision de l’ensemble du processus de contrôle d’accès. Les événements sont enregistrés. Cela permet de détecter les tentatives de violations (offline : après les faits ; ou en temps réel) Les sujets détiennent des privilèges sur des objets suivant une politique de contrôle d’accès mise en œuvre par le moniteur de référence.. 2.1.2 Politiques et mécanismes Le contrôle d’accès détermine les autorisations et les restrictions, en correspondance avec une politique de sécurité.

Le contrôle d’accès est un problème délicat, en particuliers lorsqu’on compare plu- sieurs sujets. Il existe des rôles différents (utilisateurs normaux, super-utilisateur), des groupes (étudiants, professeurs). Il peut également y avoir un besoin de déléguer ses droits. Pour résoudre les problèmes de contrôles d’accès plusieurs politiques de sécurité (DAC, MAC, RBAC), mécanismes (matrice d’accès : ACL, capabilities) ont été mis en œuvre.

2 LINUX SECURITY MODULES 5 FIG. 1 – Modèle général de sécurité Discretionary Access Control C’est la politique la plus simple. Son nom vient du fait que la discrétion est laissée à l’utilisateur. Par exemple les droits UNIX. Les droits sont lecture, écriture et exécution. L’uti- lisateur peut changer les droits sur les objets qu’il possède. Ce type de politique comporte d’importants défauts : – La politique globale de sécurité peut être compromise par un seul utilisateur s’il com- met une erreur – le flux d’information n’est pas du tout contrôlable : un utilisateur capable de lire des données peut les transmettre à un utilisateur non autorisé. Matrice d’accès C’est le mécanisme de contrôle d’accès le plus complet. Il faut identifier les relations entre les sujets et les objets. Les sujets sont les lignes, et les objets sont les colonnes de la matrice. Une telle matrice est énorme et creuse, donc peu pratique. Cette matrice est généralement représentée sous forme de liste.

2 LINUX SECURITY MODULES 6 Access Control List Cette liste représente l’ensemble des colonnes de la matrice de contrôle d’accès. Pour chaque objet, on associe les utilisateurs avec les opérations auxquels ils peuvent effectuer. Capability List Cette liste représente les lignes de la matrice de contrôle d’accès. Pour chaque sujet, on associe les objets auxquels il peut accéder, avec les opérations autorisées. Role-Based Acces Control Ce mécanisme introduit ici la notion de classe d’équivalence, avec la matrice de contrôle d’accès. Une classe (groupe ou rôle) regroupe plusieurs sujets. Ces classes sont utiles lorsque les sujets changent fréquemment, ce qui permet d’éviter de recalculer la matrice. Le modèle de rôles le plus utilisé est l’RBAC basique. Les sujets n’ont pas directement de droits. Les rôles ont des droits. Les sujets sont affectés à des rôles. Ce modèle est donc une indirection entre les sujets et les permissions.

FIG. 2 – RBAC basique D’autres modèles proposent des hiérarchies de rôles, et des contraintes sur les rôles. Mandatory Access Control Ce contrôle est basé sur l’utilisation de labels associés aux objets et aux sujets. – Le label d’un sujet (clearance, accréditation) indique le niveau de confiance de ce sujet. – Le label d’un objet spécifie le niveau minimal que doit avoir un sujet pour accéder à l’objet en question.

Conclusion Il existe de nombreux autres modèles de contrôles d’accès, chacun avec ses objectifs. Lorsque Linus Torvalds a voulu que la sécurité entre dans le noyau, il ne voulait pas impo- ser un modèle précis. Ainsi les LSM constituent une architecture, et non pas un modèle. On peut remarquer que les LSM ne constituent pas une nouveauté et que d’autres architectures existaient déjà (GFAC, Flask)

2 LINUX SECURITY MODULES 7 2.2 Architecture des LSM L’architecture des LSM est intégrée dans le noyau. Elle est constituée de points de contrôle et de champs de sécurité. Les points de contrôle sont situés aux endroits cri- tiques dans le code du noyau. Des champs ont été ajoutés, et sont destinés à contenir des informations de sécurité. Aucune sécurité n’est ajoutée par le LSM, tout le mécanisme du contrôle d’accès ré- side donc dans le ou les modules qui seront utilisés.

Le patch LSM enlève le mécanisme de capabilities du noyau, ajoute l’architecture nécessaire aux points de contrôles, et ajoute les champs de sécurité. Les capabilities deviennent alors un module de sécurité, utilisant l’architecture LSM. 2.2.1 Points de contrôle Un point de contrôle est simplement un appel à une fonction. Cette fonction va autoriser ou refuser l’accès demandé. Son adresse est stockée dans une structure pointée par la variable globale security_ops. Le type de cette variable est security_operations.

struct security_operations { int (*sethostname) (char *hostname); int (*setdomainname) (char *domainname); int (*reboot) (unsigned int cmd); ... } Chaque module de sécurité doit donc fournir une structure de ce type. Un module doit s’enregistrer pour être chargé par le noyau. Lorsqu’il est chargé, il s’enregistre et fait poin- ter la variable security_ops vers sa structure référençant ses fonctions de contrôle d’accès. Voici un exemple de hook (ancre) pour le reboot : la fonction reboot du module est consultée pour l’autorisation du rédémarrage du système. /* kernel/sys.c */ asmlinkage long sys_reboot(int magic1, int magic2, unsigned int cmd, void * arg) { char buffer[256]; int retval; /* We only trust the superuser with rebooting the system. */ if (!capable(CAP_SYS_BOOT)) return -EPERM; retval = security_ops->reboot(cmd);

2 LINUX SECURITY MODULES 8 if (retval) { return retval; } ... Pour les noyaux 2.5.X/2.6.X, le point de contrôle se présente sous la forme d’un appel à une fonction inline qui se charge de déréférencer security_ops et d’appeler la fonction du module de sécurité utilisé. /* include/linux/security.h */ static inline int security_reboot (unsigned int cmd) { return security_ops->reboot (cmd); } Ce double appel est équivalent à la version des noyaux 2.4.X, car la fonction est inline. L’avantage est que l’appel est plus propre, pour la consultation d’autorisation du reboot, il devient : /* We only trust the superuser with rebooting the system. */ if (!capable(CAP_SYS_BOOT)) return -EPERM; retval = security_reboot(cmd); if (retval) { return retval; } Les points de contrôle sont évidemment placés à des endroits stratégiques. Ils sont systématiquement situés juste après les vérifications standards. Dans notre exemple précédent la fonction capable est appelée juste avant la fonction security_reboot du module de sécurité.

C’est uniquement après les vérifications préalables (capable()), et en cas de non échec, que le hook (ancre) du LSM est appelé. Le reboot est effectué uniquement si le hook le permet. Conséquences – les arguments reçus par les points de contrôle sont déjà en espace noyau et les contrôles d’erreur ont déjà été effectués. – les tests du LSM sont effectués en dernier. Si un seul des tests précédents échoue, les tests du LSM ne seront donc pas pris en compte. Un point de contrôle ne peut donc pas modifier une décision antérieure (ni postérieure).

2 LINUX SECURITY MODULES 9 – les points de contrôle sont restrictifs : Par défaut l’accès est valide. Leur rôle est donc de déterminer les situations où l’accès doit être refusé. Le module par défaut ne s’oppose pas à la demande, les accès sont autorisés. Ce module est définit dans security/dummy.c (module dummy). Tous ces points de contrôle renvoient 0. /* security/dummy.c */ static int dummy_reboot (unsigned int cmd) { return 0; } 2.2.2 Champs de sécurité Définition des Champs Pour mettre en œuvre une politique de sécurité, il nécessaire de conserver des don- nées, servant à prendre les décisions sur l’accès à l’objet. Par exemple, dans le modèle BLP2 (MAC), chaque objet possède un label, son ni- veau de sécurité. La solution la plus simple, pour ajouter des données, est de prévoir pour chaque objet du noyau un champ void * destiné à contenir les informations de sécurité. Le champ de sécurité est donc un pointeur initialisé à NULL. Les définitions des struc- tures se trouvent dans les sources du kernel dans le répertoire include/linux/. Le tableau suivant montre les champs de sécurité ajoutés aux noyau. Objet Header Structure champs Programme binftms.h struct linux_binprm void *security Processus sched.h struct task_struct void *security FileSystem fs.h struct super_block void *s_security Fichier fs.h struct inode void *i_security - fs.h struct file void *f_security Paquet skbuff.h struct sk_buff void *lsm_security Net dev netdevice.h struct net_device void *security IPC ipc.h struct kern_ipc_perm void *security - msg.h struct msg_msg void *security Les objets fichiers désignent des fichiers, des pipes ou des sockets. 2modèle, élaboré en 1975 : Bell-La Padula (BLP), du nom de ses concepteurs.

2 LINUX SECURITY MODULES 10 Gestion des Champs Il est impératif de gérer ces pointeurs (allocation, initialisation, libération, modification, etc.). Pour cela des points de contrôle ont donc été mis en place pour les gérer. Gestion mémoire des Champs Pour chaque structure contenant un champs de sécurité, les hooks _alloc_security() et _free_security() sont définis. Dans le cas d’une réussite, ces fonctions re- tournent 0. Leur argument est la structure dans laquelle on souhaite attacher une structure de sécurité.

Voici un exemple pour la structure inode, hook d’allocation du champs de sécurité pour un inode. /* include/linux/security.h */ static inline int security_inode_alloc (struct inode *inode) { return security_ops->inode_alloc_security (inode); } Dans les sources du module de sécurité, on trouve le code associé à la gestion du champs, à nouveau un exemple pour SELinux : /* security/selinux/hooks.c */ static int inode_alloc_security(struct inode *inode) { struct task_security_struct *tsec = current->security; struct inode_security_struct *isec; isec = kmalloc(sizeof(struct inode_security_struct), GFP_KERNEL); if (!isec) return -ENOMEM; memset(isec, 0, sizeof(struct inode_security_struct)); init_MUTEX(&isec->sem); INIT_LIST_HEAD(&isec->list); isec->magic = SELINUX_MAGIC; isec->inode = inode; isec->sid = SECINITSID_UNLABELED; isec->sclass = SECCLASS_FILE; if (tsec && tsec->magic == SELINUX_MAGIC) isec->task_sid = tsec->sid; else isec->task_sid = SECINITSID_UNLABELED;

2 LINUX SECURITY MODULES 11 inode->i_security = isec; return 0; } Mise à jour des Champs Il est également nécessaire de mettre à jour ces champs de sécurité. D’autres hooks ont été insérés, ils sont nommés _post_. Le contrôle d’accès est d’abord vérifié, et dans le cas d’un succès, la mise à jour du champs est appelé. Voici un exemple pour la création d’un lien symbolique : – le hook de contrôle d’accès /* include/linux/security.h */ static inline int security_inode_symlink (struct inode *dir, struct dentry *dentry, const char *old_name) { return security_ops->inode_symlink (dir, dentry, old_name); } – le hook de mise à jour /* include/linux/security.h */ static inline void security_inode_post_symlink (struct inode *dir, struct dentry *dentry, const char *old_name) { security_ops->inode_post_symlink (dir, dentry, old_name); } – la création d’un lien symbolique /* fs/namei.c */ int vfs_symlink(struct inode *dir, struct dentry *dentry, const char *oldname) { int error;

2 LINUX SECURITY MODULES 12 down(&dir->i_zombie); error = may_create(dir, dentry); if (error) goto exit_lock; error = -EPERM; if (!dir->i_op || !dir->i_op->symlink) goto exit_lock; error = security_inode_symlink(dir, dentry, oldname); if (error) goto exit_lock; DQUOT_INIT(dir); lock_kernel(); error = dir->i_op->symlink(dir, dentry, oldname); unlock_kernel(); exit_lock: up(&dir->i_zombie); if (!error) { inode_dir_notify(dir, DN_CREATE); security_inode_post_symlink(dir, dentry, oldname); } return error; } 2.2.3 Communication avec l’espace utilisateur Il est relativement facile d’ajouter des données de contrôle en utilisant les champs de sécurité. Toutefois, cela se passe uniquement en espace noyau. Pourtant un utilisateur pourrait très bien souhaiter connaître, si la politique de sécurité le permet, ses propres permissions, ou celles nécessaires sur certains objets. On peut imaginer une commande lsperm, renvoyant les permissions.

Il est donc nécessaire de fournir une interface entre l’espace utilisateur (espace d’ap- pel de la commande lsperm) et l’espace noyau (espace où sont stockées les informations de sécurité) La première solution envisagée fut la mise en place d’un appel système sys_security(). Cette solution ne fut pas retenue, pour deux raisons : – pour éviter de mettre en place un appel système non standard, – mais surtout qui servirait à tout ou rien, puisque sa fonction serait propre à chaque module.

2 LINUX SECURITY MODULES 13 La solution actuellement retenue repose sur le système de fichiers /proc, mais chaque LSM est libre de faire comme bon lui semble. L’architecture intègre dans la structure secu- rity_operations deux pointeurs sur fonction destinés à communiquer avec l’espace utilisa- teur via /proc. /* security/selinux/hooks.c */ int (*getprocattr)(struct task_struct *p, char *name, void *value, size_t size) int (*setprocattr)(struct task_struct *p, char *name, void *value, size_t size) Les répertoires /proc// contiennent maintenant un répertoire attr/, qui contient les entrées correspondant aux labels de sécurité que l’on souhaite connaître, ou même fixer. Ces entrées appellent directement les fonctions précédentes, avec le paramètre name valant le nom du fichier dans attr/ auquel nous accédons.

2.2.4 Tests de consistance Une des grosses difficultés des politiques de contrôle d’accès, est de pouvoir prouver leur consistance. Il faut donc parvenir à montrer que l’architecture LSM est consistante c’est à dire qu’elle n’oublie pas de contrôler un point particulier qui permettrait de contourner un autre point de contrôle. La consistance d’une politique d’accès pour une ressource est donc de contrôler tous les moyens qui permettent l’accès à cette ressource.

Cette consistance n’est pas réellement prouvable au sens mathématique, vu le travail que nécessiterait la modélisation du noyau Linux. Cependant des travaux très intéressants ont été menés par Zhang[1], Edwards et Jae- ger. Ces travaux ont abouti au document Using CQUAL for Static Analysis of Authorization Hook Placement pour atteindre un degré de confiance correct. L’objectif de leurs travaux a donc été de prouver la correction des placements des hooks. Pour cela, ils ont utilisé CQual[2], un outil d’analyse statique basé sur le typage. Il permet d’ajouter des attributs aux types, et de calculer la correction à partir de règles d’inférence avec les attributs. C’est donc un moyen d’ajouter des spécifications aux programmes.

Complete mediation Cette vérification se déroule en deux étapes. Tout d’abord il s’agit de s’assurer de la complétude du principe de médiation (complete mediation, aussi appelée reference moni-

2 LINUX SECURITY MODULES 14 tor). Cela signifie que le mécanisme de contrôle d’accès doit être capable d’intercepter et d’empêcher tous les accès à une ressource. Dans le cas contraire, la sécurité ne peut être garantie. C’est le problème avec la protection d’un réseau interne, si une seule route per- met d’atteindre un élément du réseau interne sans passer par le pare-feu, alors ce dernier ne sert à rien.

Chaque objet doit donc subir une opération de contrôle par un hook avant d’être utilisé. Seuls les objets accessibles en espace utilisateur sont concernés. FIG. 3 – preuve du principe de médiation Complete authorization La deuxième étape de la vérification est de s’assurer que toutes les opérations de contrôle ont bien été effectuées avant l’utilisation d’un objet, pour tous les chemins pos- sibles entre l’initialisation et l’utilisation. Il s’agit donc de vérifier la complétude de l’autori- sation.

Cette opération coule relativement de source une fois le problème de médiation résolu. Approche suivie Cette vérification est effectuée à l’aide des opérations suivantes : 1. détermination des fonctions qui initialisent les objets 2. détermination des fonctions qui utilisent les objets 3. détermination des fonctions qui autorisent les accès aux objets 4. vérification que toutes les manipulations d’objets dans les fonctions d’autorisations sont réalisées après le contrôle d’accès 5. vérification qu’il n’y ait pas d’affectation de l’objet après son contrôle d’accès 6. détermination des chemins d’exécution entre l’initialisation et l’utilisation de l’objet 7. vérification de la présence d’au moins une opération de contrôle dans chaque che- min

2 LINUX SECURITY MODULES 15 FIG. 4 – preuve de l’autorisation Vulnérabilités Bien que cette vérification ne permette pas une preuve mathématique de la sécurité de l’architecture, elle a néanmoins permis d’identifier trois types d’erreur. – Inconsistance de la vérification : La variable qui est vérifiée n’est pas celle qui sera utilisée par la suite. Une condition de concurrence (race condition) a été identifiée, pouvant conduire à une exploitation. Une preuve de concept a été montrée. La vérification était effectuée sur un objet de type struct file, mais la suite des opérations sur le descripteur de fichiers.

– Modification d’un objet contrôlé sans vérification de sécurité : Cela se produit lorsqu’un objet non contrôlé, mais censé avoir été contrôlé, est uti- lisé. Un exemple d’une telle situation était le suivant : Une page fault se produisait, l’objet file manipulé dans ce cas n’a pas subi de contrôle d’accès. Il est toutefois passé à la fonction page_cache_read qui appelle une sous-fonction pour lire la page en question, en prenant l’objet file en argument.

Cet exemple illustre que la lecture d’un fichier après mmap(), ne se soucie pas d’éventuelles modifications des attributs de sécurité du fichier, une fois celui-ci mis en mémoire. Désormais, le contrôle n’est systématique que pour les fichier non mis en mémoire (par mmap()), les fichiers mis en mémoire n’étant contrôlés qu’au mo- ment de la lecture pour chargement. – Problème de typage : Ce problème survient lorsqu’une opération est réalisée sur un objet d’un type donné, alors que c’est un autre type qui est attendu.

L’analyse des auteurs s’appuie sur une analyse statique du typage des objets, qui sont soit checked soit unchecked.

2 LINUX SECURITY MODULES 16 Conclusion sur la consitance Le problème de l’approche des auteurs est un taux très élevé de faux positifs, c’est à dire d’endroits où l’analyseur détecte une faille alors qu’il n’y en a pas. Malgré cela, ces travaux ont permis de donner une garantie de sécurité, non absolue mais suffisante, à l’architecture des LSM. 2.2.5 Enregistrement et empilage des LSM Enregistrement Nous avons vu qu’un module de sécurité est en fait un tableau de pointeurs sur des fonctions. Pour qu’il soit utilisé, il est nécessaire de signaler au noyau son enregistrement. Cela se fait au chargement du module par l’appel à la fonction register_security(). De la même manière, le déchargement est effectué par l’appel à la fonction unregis- ter_security().

Empilement Il peut-être souhaitable de combiner plusieurs module de sécurité, afin de bénéficier de plusieurs politiques de contrôle d’accès. Lorsqu’un module est déjà enregistré, l’appel à la fonction register_security() échouera. Il est cependant possible de s’enregistrer auprès du module déjà enregistré en appelant mod_reg_security(). L’accord de chargement dépendra de celui-ci. S’il accepte, les appels aux hooks dé- pendront également de celui-ci. Il est possible que les demandes d’autorisation ne soit pas systématiques.

Dans la situation où un module A est dépendant d’un autre module B, lorsque le mo- dule B se décharge, le module B devrait appeler la fonction mod_unreg_security() du mo- dule A avant de se décharger. Lorsque plusieurs modules sont chargés, ces modules constituent en fait une liste. Chaque module est alors en charge d’appeler, s’il le souhaite, les contrôles du module suivant.

2 LINUX SECURITY MODULES 17 Exemple standard /* LSM-standard */ /* 1 si présence d’un autre module avant */ static int secondary; /* définition des opérations du module */ struct security_operations facist_ops = { ... } static int init_module(void) { ... /* enregistrement */ if (register_security(&facist_ops)) { printk(KERN_INFO "échec de l’enregistrement\n"); /* tentative en contactant le module précédent */ if (mod_reg_security(MY_NAME, &facist_ops)) { printk(KERN_INFO "échec auprès module précédent\n"); return -EINVAL; } secondary = 1; } printk(KERN_INFO "facist LSM chargé\n"); return 0; } static void exit_module(void) { /* on se retire de l’architecture LSM */ if (secondary) { if (mod_unreg_security(MY_NAME, &facist_ops)) { printk(KERN_INFO "échec du déchargement secondaire\n"); return; } } if (unregister_security(&facist_ops)) { printk(KERN_INFO "échec du déchargement\n"); } }

2 LINUX SECURITY MODULES 18 Un module de sécurité doit également prévoir le chargement et le déchargement d’un module secondaire. /* pointeur sur les hooks du successeur */ struct security\_operations *next\_ops; Un module de sécurité peut consulter systématiquement un autre module pour l’auto- risation du reboot : static int facist_reboot(unsigned int cmd) { int res = -EPERM; if (next_ops->reboot) res = next_ops->reboot(cmd); return -EPERM; } ou ne jamais consulter l’autre module : static int facist_reboot(unsigned int cmd) { return -EPERM; } SELinux SELinux ne peut pas être chargé comme module secondaire. Il ne possède pas la va- riable int secondary et la fonction de chargement mod_reg_security() SELinux permet le chargement secondaire des modules dummy, capability et owlsm (cf. security/selinux/hooks.c). /* security/selinux/hooks.c */ struct security_operations selinux_ops = { .ptrace = selinux_ptrace, .capget = selinux_capget, .capset_check = selinux_capset_check, ...

.inode_alloc_security = selinux_inode_alloc_security, .inode_free_security = selinux_inode_free_security, ... .inode_symlink = selinux_inode_symlink, ... .register_security = selinux_register_security, ...

2 LINUX SECURITY MODULES 19 .getprocattr = selinux_getprocattr, .setprocattr = selinux_setprocattr, ... }

3 ARCHITECTURE DE SELINUX 20 3 Architecture de SELinux SELinux est basé sur le modèle de l’architecture Flask, que nous allons détailler. Il a été conçu tout d’abord sous forme de patch pour le noyau Linux. Puis, avec la création des LSM, il a progressivement évolué vers une implémentation utilisant ce framework de sécurité dans le noyau, apportant d’ailleurs une forte contribution au développement du projet LSM.

3.1 Mandatory Acces Control La politique de contrôle d’accès typique d’un système Unix est laissée à la discrétion de l’utilisateur. C’est le DAC, ou Discretionary Acces Control. La protection apportée par SELinux est fondée sur la principe de MAC, Mandatory Acces Control. Le MAC s’appuie sur l’utilisation de labels associés à des sujets (processus) et à leurs objets (fichiers, so- ckets . Son but est alors de vérifier, à partir d’une politique de sécurité prédéfinie, la légitimité de tous les accès des sujets aux objets. Ici, l’utilisateur n’est plus maître des objets qu’il possède, et c’est ce qui permet de baisser par exemple les capacités de root. Le MAC n’est cependant pas l’apport principal de SELinux. C’est en fait l’utilisation de l’architecture Flask, déployée dans le noyau pour implémenter le MAC. 3.2 Le modèle Flask Flask est une sorte de charpente autorisant l’implémentation de différents modèles de sécurité. Il a donné lieu plus tard à la création des LSM, par Linus Torvalds et sa commu- nauté.

Flask repose sur la séparation entre le code de décision et le code d’application de la politique de sécurité. La partie décisionnelle de l’architecture de SELinux est conte- nue dans un composant particulier du noyau, et établit les lois à appliquer sur le système. C’est le référentiel de sécurité. La partie d’application est elle intégrée directement dans les composants du noyau gérant les processus, les systèmes de fichiers, les IPC et le réseau.

Enfin, SELinux supporte un cache, pour l’accès rapide aux décisions déjà calculées. C’est l’Access Vector Cache, ou AVC. Ce modèle devant être indépendant de la polique de sécurité à appliquer, les intéractions sujets-objets sont modélisées : Chaque entité du système reçoit un label, ou contexte de sécurité. Il contient les informations relatives à cette entité, pour déterminer avec qu’elles autres entités, et comment, elle peut intérargir. Ces contextes sont associés à un entier pour simplifier leur manipulation, le Security IDentifier, ou SID. Dans le cas des fichiers enregistrés sur des mémoires de masse, les SID deviennent persistants et sont enregis- trés directement dans le système de fichier. Ce sont les PSID. Les objets du systèmes se voient de plus attribuer une classe, à laquelle sont associées des permissions. (par exemple la classe ’file’, avec les permissions ’open’ ou ’link’).

3 ARCHITECTURE DE SELINUX 21 Les décisions du référentiel de sécurité reposent donc sur les contextes de sécurité attribués au couple (sujet,objet) et sur la classe de l’objet. Ces décisions sont de deux types, accès et transition. Les décisions d’accès spécifient si une certaine permission est accordée ou refusée pour un couple de SID (source et cible), et la classe de l’objet cible. Le SID source est celui du sujet, le SID cible est celui de l’objet. Concrètement, le référentiel de sécurité fournit un tableau de l’ensemble des permissions associées à la classe de l’objet pour le couple de SID source et cible. (C’est ce tableau qui est enregistré dans l’AVC). Il fournit aussi deux tableaux qui spécifient les besoins de journalisation (audit) associés à la classe de l’objet (auditallow en cas de succès, auditdeny en cas d’echec).

Les décisions de transitions attribuent des labels aux nouveaux objets, et existent sous deux formes : – transition de processus – transition d’objet Une décision de transition de processus a lieu lors de l’exécution d’un nouveau pro- gramme, à partir du SID du processus demandant et du SID du fichier à exécuter. Une décision de transition d’objet a lieu lors de la création d’un nouvel objet, à partir du SID du programme créant l’objet et du SID d’un objet ’parent’. Par exemple le dossier pa- rent s’il s’agit d’un fichier. De plus, une application peut fournir directement le label attribué au nouvel objet, en utilisant des fonctions de SELinux. Cette application doit cependant être autorisée à modifier le contexte de sécurité et une telle transition doit être permise par une décision d’accès correspondante. Par exemple, un utilisateur se connectant via SSH va recevoir un SID lui correspondant, et non le SID par défaut.

3.3 Modèles de sécurité SELinux offre la possibilité d’utiliser différents modèles de sécurité. Si les possibilités seront différentes suivant le modèle choisi, les principes de fonctionnement vont eux rester inchangé. Le modèle implémenté actuellement est une combinaison de Type Enforcement et de Role-Based Access Control (RBAC). Une implémentation de Multi-Level Security est en cours mais reste encore expéri- mentale, ainsi qu’une implémentation de Labeled Networking Support. 3.3.1 Type Enforcement Le modèle de security Type Enforcement (TE) est dérivé du modèle Domain and Type Enforcement (DTE). Dans DTE, tous les objets et processus du système reçoivent des at- tributs de sécurité. Ils sont nommés domaines pour les processus et types pour les objets. Les processus d’un même domaine et les objets d’un même type sont traités de façon identique.

3 ARCHITECTURE DE SELINUX 22 Le modèle TE diffère de l’original par le fait qu’il n’a q’un seul type d’attributs de sé- curité. Les domaines sont en fait des types qu’il faut associer à des processus pour se rapprocher au mieux de DTE. En pratique, la définition d’un type ou d’un domaine devient identique, SELinux ne faisant plus de différence en interne. Une autre différence de SELinux par rapport au modèle original est la notion de classe d’objet qui provient de Flask. Deux objets du même type mais de classe différente peuvent alors être traités différemment, ce qui permet donc un contrôle très fin des exécutions et transitions de domaines.

Enfin, TE n’associe pas les utilisateurs directement à des domaines, mais à des rôles. Un rôle détermine quels domaines peuvent être utilisés. TE permet alors de définir des lois d’accès et de transition, avec pour chacun de ces deux types un comportement par défaut. Ainsi, une demande d’accès donnée est refusée si aucune loi n’existe qui lui correspond. Pour les transitions, SELinux se base sur la conservation du domaine pour les processus, et l’héritage du type du parent pour les objets.

3.3.2 Role-Based Access Control Le modèle original de RBAC assigne des rôles aux utilisateurs, et des permissions à ces rôles. SELinux associe à chaque utilisateur un ensemble de rôles, et à chaque rôle un ensemble de domaines de TE. Il combine ainsi les facilités de gestion du RBAC et la finesse de contrôle de TE. Les rôles sont inclus dans les contextes de sécurité associés aux sujets et objets du système. Puisque SELinux permet de définir des règles de tran- sition de rôles pour les processus, les UID traditionnelles de Linux ne conviennent plus. En effet, un programme lancé par root peut prendre n’importe quelle UID via les fonctions set*uid.

SELinux introduit donc un attribut indépendant de l’UID, et définissant l’identité de l’utilisateur dans le contexte de sécurité. Il peut ainsi effectuer des contrôles sur l’identité de l’utilisateur sans perturber le DAC. En pratique, seuls certains domaines ont la possibilité de modifier l’identité d’un utilisa- teur. Les programmes login et sshd font par exemple partie de ces domaines. L’avantage certain procuré par de tels mécanismes et une meilleure traçabilité des utilisateurs. Un utilisateur utilisant la fonction su conservera toujours son identité SELinux.

3 ARCHITECTURE DE SELINUX 23 3.3.3 Multi-Level Security C’est un cas particulier de MAC. Le label d’un objet spécifie alors le niveau minimal que doit avoir un sujet pour accéder à cet objet. L’on définit par exemple 4 labels (top secret, secret, confidentiel et non classifié). Puis on définit 2 règles systématiquement appliquées : – read down : l’accréditation d’un sujet doit dominer le niveau de sécurité de l’objet qu’il lit – write up : l’accréditation d’un sujet doit être dominée par le niveau de sécurité de l’objet qu’il écrit On garantit (mathématiquement) ainsi la confidentialité des objets en fonction des ni- veaux d’accréditation. C’est le modèle Bell-La Padula (BPL). Le modèle MLS prévu dans SELinux en est très proche.

Notons que le modèle inverse (read up, write down), ou modèle de Biba, garantit quant à lui l’intégrité des données. Notons de plus que l’implémentation de MLS au sein de SELinux n’est pas encore terminée. Au stade expérimental où elle se trouve actuellement, il est déjà possible d’as- socier ces niveaux de confidentialité à toutes les entités du système. 3.3.4 Labeled Networking Support SELinux comporte également un modèle de trafic réseau labellisé. Il repose sur une nouvelle option de l’en-tête IP décrite dans CIPSO/FIPS-188. L’objectif de LNS est de pou- voir associer les paquets IP à des SID. Ces paquets seront décodés par le destinataire du traffic, selon le protocole Security Context Mapping Protocol (SCMP).

LNS ne peut être mis en place que sur un parc de machines où les politiques SELi- nux sont équivalentes, ce parc devant être déclaré dans la configuration de la politique. Ce modèle ne définit cependant pas de protection du trafic, qui doit alors être apporté de manière annexe. Dans la documentation actuelle de SELinux et dans les implémentations existantes, quelque soit la distribution, nous n’avons vu aucun exemple concret de mise en place de LNS. Ce modèle repose en effet sur un parc de machines, et SELinux n’est pour le moment supporté que sur des serveurs, et là rien n’a encore été prévu pour une gestion simple ainsi que la propagation d’une politique de sécurité.

4 INTÉGRATION DE SELINUX 24 4 Intégration de SELinux Si la partie de SELinux implémentant les LSM fait partie du noyau, il reste plusieurs utilitaires et démons à modifier afin de prendre en compte l’environnement SELinux. 4.1 dans le noyau Si l’on se place dans le répertoire contenant les sources du noyau (usr/src/linux), on trouve le dossier security. Il contient les modules utilisant l’architecture LSM, ainsi que le code spécifique à SELinux, dans selinux/.

SELinux implémente l’ensemble des ancres fournis par LSM, les fonctions correspon- dantes étant définies dans le fichier hooks.c. 4.2 dans les démons et utilitaires La principale librairie utilisée par les programmes pour accèder aux fonctions de com- munication avec l’environnement SELinux est libsecure. Cette bibliothèque fournit des mécanismes propre à LSM permettant à SELinux, qui se trouve dans l’espace noyau, d’intéragir avec les processus standards. Cette communication se fait par des entrées spécifiques dans /proc.

Deux catégories de programmes utilisent libsecure : – les démons et utilitaires classiques modifiés (sshd, login, ls, ps...) – les nouveaux utilitaires fournis avec SELinux (runas, setfiles, checkpolicy , qui permettent entre autre d’assigner des labels au système de fichier, ou de manipuler la politique de sécurité.

5 ETUDE DE LA MISE EN ŒUVRE SUR MANDRAKE 25 5 Etude de la mise en œuvre sur Mandrake 5.1 Contexte Cette étude pratique est réalisée dans le cadre du projet proposé par le service des Moyens Informatiques (MI) du Loria (Laboratoire lOrrain de Recherche en Informatique et ses Applications). La problématique initialement proposée était de tester SELinux sur la distribution Linux officiellement utilisée dans ce centre de recherche avec un certain nombre de contraintes fonctionnelles que nous allons décrire par la suite. 5.2 Objectifs Les deux objectifs initiaux de ce projet étaient : – l’étude du système SELinux (installation, compréhension du fonctionnement, confi- guration des options) et de ses différentes fonctionnalités – la mise en situation pratique de SELinux dans le cadre de la réalisation d’un ser- veur d’accès externe SSH. Ce serveur d’accès a pour fonction de fournir un accès au réseau interne via SSH aux utilisateurs du Loria se trouvant sur un réseau extérieur. Le premier objectif a été réalisé. Le second n’a pas pu aboutir du fait de contraintes spécifiques...

5.3 Contraintes Les contraintes apparues sont directement liées au contexte dans lequel cette étude s’est réalisée. Nous pouvons les résumer comme suit : – La distribution Linux utilisée doit être une Mandrake, et plus particulièrement celle utilisée au Loria. – Les comptes des utilisateurs du système à étudier sont des comptes itinérants, ac- cessible par le couple de services NIS et NFS. – Un utilisateur doit pouvoir utiliser ses outils habituels, contrainte que nous avions, dès le démarrage du projet et au vues des problèmes de configuration des poli- tiques de sécurité, restreint à l’utilisation de SSH, de Mozilla, de XEmacs et de Vim. À partir du moment où il nous a été imposé l’utilisation de la distribution Mandrake nous avons manifesté quelques réticences face à ce choix. La principale justification que nous avions reste celle couramment évoquée lorsque l’on traite de SELinux, à savoir que SELinux n’est pas destiné a être utilisé sur une distribution de type station de travail mais plutôt pour un serveur. Ce point est important car nous verrons par la suite qu’il est la cause initiale d’un manque total de support sur SELinux pour cette distribution.

5 ETUDE DE LA MISE EN ŒUVRE SUR MANDRAKE 26 5.4 Réalisation Nous ne parlerons pas ici de la partie installation et administration de la machine qui nous a été livrée “vierge”. Toutefois il est important pour la suite de noter deux particulari- tés de cette installation : – la distribution Mandrakefournie est spécifique au Loria et a été installée entière- ment (installation par défaut, avec tous les paquets proposés).

– les comptes utilisateurs sont itinérants, authentifiés via NIS et montés via NFS La partie “hardware” quant à elle n’a aucune incidence, si ce n’est l’espace mémoire vive disponible qui, nous le verront plus loin, constitue un réel problème pour le montage des répertoires des utilisateurs. Le travail effectif sur l’étude de SELinux a commencé par la recherche d’un noyau 2.4.X SELinux pour la distribution Mandrake, la branche 2.6.X nous est apparue encore trop risquée du fait de sa jeunesse relative et des dépendances qu’elle imposait (sur les nouveaux outils de gestion des modules en l’occurrence). Nous avons fini par compiler notre propre noyau, non sans mal, ce sera expliqué plus loin. Une fois notre noyau apte, notre second travail a été de mettre en place les outils propres à SELinux. Ces outils permettent d’accéder depuis l’espace utilisateur aux fonc- tions avancées des modules de sécurité de SELinux et assurent, entre autre, la gestion et le chargement des politiques de sécurité. Nous verrons qu’il est coûteux en temps, du fait du manque de support, de disposer de ces outils sous Mandrake.

Une fois ces outils disponibles nous avons tenté plusieurs chargements de politiques rendant de manière systématique l’ensemble du système inutilisable. Et comme aucun “patch” ni aucun paquet de base de la distribution Mandrake supportant SELinux n’était disponible, l’exploration de SELinux sur celle-ci s’est arrêtée là. En effet le temps nécessaire pour refaire l’ensemble minimal des éléments de base du sys- tème pour que SELinux soit fonctionnel sous Mandrake a fait que le projet initial n’était pas du tout réalisable dans les temps impartis et ne nous a pas permis d’aller plus en avant. Tout est détaillé dans la section suivante.

Concernant le travail effectué, dans le but initial de ce projet, nous regrettons toutefois de ne pas avoir eu accès à un système sous SELinux qui soit fonctionnel et donc d’avoir pu réaliser le moindre test probant sur celui-ci, ni tenté la mise en place d’au moins une politique particulière souhaité à l’origine. Nous avons noté, à titre indicatif et personnel, qu’à partir de l’installation d’une distribution Debian minimale (juste le support du réseau) et l’ajout de quelques sources apt supplémentaires, la mise en place d’un système minimal sous SELinux reste beaucoup plus abordable : tout est fourni, noyau, outils SELinux, version SELinux des outils du système de base, librement.

5 ETUDE DE LA MISE EN ŒUVRE SUR MANDRAKE 27 5.5 Problèmes rencontrés Nous avons dû faire face à plusieurs types de problèmes lors de nos tentatives de mise en place d’un noyau sécurisé SELinux sur la Mandrake. 5.5.1 Liés à la compilation du noyau SELinux La distribution Mandrake ne fournissant en standard aucun noyau précompilé ou “patch” spécifique nous avons été contraint de le générer notre propre noyau SELinux. Dans un premier temps nous avons tenté d’utiliser les noyaux fournis en paquets de sources par la distribution Mandrake et nous sommes de suite retrouvés confrontés à des incompa- tibilités avec le noyau “vanilla” (l’officiel de kernel.org) et donc avec les patchs officiels proposés par la NSA.

Dans un second temps, nous nous sommes rabattus sur la version officielle des sources, or notre préoccupation initiale était de trouver un noyau possédant encore une faille ex- ploitable qui nous aurait permis de démontrer l’efficacité de SELinux dans le cadre d’un exploit local donnant les droits root. Et là, surprise, la NSA ne fournit que le patch pour le dernier noyau stable : impossible de trouver, de manière officielle, le patch NSA d’un noyau Linux devenu obsolète pour des raison de sécurité. Le problème avec les patchs récupérés sur Internet, c’est qu’aucun d’entre eux ne s’appliquait correctement sur les ver- sions des sources que nous avions ciblées (de 2.4.20 à 2.4.24).

Toutefois, à force de parcourir le site de la NSA[3], au fil des pages non mises à jour, nous avons pu récupérer une version 2.4.24 vulnérable à l’exploit mremap_pte : archives linux-2.4-2004021907.tgz pour le noyau et selinux-usr-2004021907.tgz pour les utilitaires correspondant (nous en reparlerons plus tard). Cette dernière fois, le patch déjà appliqué, la compilation n’a posé aucun problème. Nous nous sommes rendu compte un peu plus tard, lors de notre première utilisation des outils fournis pour SELinux, que nous avions activé une option “expérimentale” non conseillée par la NSA : MLS. SELinux était alors inutilisable : impossible de compiler la politique de sécurité.

Finalement, les bonnes options de compilation sont : – les attibuts étendus des systèmes de fichiers ext2 et ext3 : – CONFIG_EXT[23]_FS_XATTR et – CONFIG_EXT[23]_FS_SECURITY – dans les options sur les pseudo systèmes de fichier, les attributs étendus et les options de label de sécurité de /dev/pts : – CONFIG_DEVPTS_FS_XATTR et – CONFIG_DEVPTS_FS_SECURITY – et dans les options de sécurité : – CONFIG_SECURITY (activation de différents modèles de sécurité), – CONFIG_SECURITY_NETWORK (ancres de sécurité du réseau et des sockets,

5 ETUDE DE LA MISE EN ŒUVRE SUR MANDRAKE 28 – CONFIG_SECURITY_CAPABILITIES (support des capabilities), – CONFIG_SECURITY_SELINUX (support NSA SELinux), – CONFIG_SECURITY_SELINUX_DEVELOP (support de développement NSA SE- Linux) et – CONFIG_SECURITY_SELINUX_BOOTPARAM (support des paramètres de boot de NSA SELinux). 5.5.2 Liés à la distribution Mandrake Nous avons été confrontés à plusieurs problèmes inhérants à Mandrake. Tout d’abord, aucun paquet, de noyau ou d’utilitaire SELinux, n’est disponible sur cette distribution, même de manière non officielle. De plus, la présence de nombreux utilitaires propres à Mandrake (scripts, wrappers ) rend incompatible le portage des outils de la distribution la plus proche supportée par la NSA, à savoir la RedHat[4], et suppose un travail supplé- mentaire lors de la construction de la politique de sécurité. En effet, l’arborescence par défaut des paquets (tarball) fournis par la NSAcorrespond à celle de la Fédora. Aussi est-il nécessaire de reproduire celle-ci à l’aide de liens symboliques (par exemple /usr/src/redhat → /usr/src/RPM).

Pour finir, le script d’installation fournit par la NSA doit être relancé autant de fois qu’il y a de paquet à créer : il n’arrive jamais à retrouver les paquets générés... De toute façon cette solution ne peut être considérée comme viable. Elle ne couvre que la création des outils de base nécessaire à la gestion des fonctionnalités propre à SELinux. Il faut de plus construire les paquets correspondants aux démons et utilitaires qui doivent prendre en compte la politique de sécurité fournie par SELinux. Par exemple init (System V init) est le premier de ceux-ci, il doit prendre en charge dès le démarrage la pro- pagation de la politique de sécurité configurée pour le système. De même la glibc doit être “patchée” pour fournir un environnement de liaison dynamique supportant SELinux, PAM pour l’authentification, cron, OpenSSH, et l’ensemble des outils de base du système UNIX comme ls ou ps par exemple (paquets util-linux, shadow-utils, passwd, libuser, pwdb, etc.) afin de fournir un accès consultatif sur les contextes de sécurité des objets du système. Or, l’ensemble des patchs disponibles pour ces outils correspondent à des versions très précises de leurs homologues, mais sur la distribution RedHat !

Aucun des patchs disponibles ne s’applique car Mandrake et RedHat ne partagent que leur format de paquet, non les versions des logiciels de ceux-ci. De plus dans bien des cas, ceux-ci sont déjà “patchés”, mais de manière propre à chacune (pour des raisons diverses : chaque distribution effectuant ces mises à jour particulières d’une ou plusieurs fonctionnalités). Un dernier point, non des moindres, est celui des politiques de sécurité à mettre en place. En effet, la politique par défaut est très restrictive une fois SELinux activé (mode enforce), aussi est-il nécessaire d’avoir, pour tout objet du système, la bonne politique de sécurité le concernant sans quoi son utilisation se révèle impossible : blocage complet par le noyau. Et, à ce jour, personne n’a jamais entrepris de politique pour un quelconque paquet de la distribution Mandrake. Celles fournies par la NSA correspondent à celles d’une distribution RedHat et entraînent un blocage systématique de la Mandrake à partir

5 ETUDE DE LA MISE EN ŒUVRE SUR MANDRAKE 29 du moment où elles sont chargées. Pour conclure nous nous sommes arrêtés à la compilation des outils propres à SELi- nux, avons réussi à charger plusieurs politiques et, à bloquer définitivement le système : même un shutdown avec les raccourcis habituels était devenu impossible. Nous n’avons trouvé aucune issue tant le nombre de scripts/démons/outils fournis par Mandrake en standard rendent ardue une édition manuelle de ces politiques. 5.5.3 Liés au contexte Le premier problème lié au contexte concerne les “yellow pages” utilisées pour l’au- thentification des utilisateurs sur le système sécurisé. Le serveur NIS doit en effet être en mesure de fournir les informations relatives aux contextes de sécurité des différents utili- sateurs au moment de l’authentification. Ces informations n’étant pas renseignées dans le service existant, l’utilisation seule du client NIS patché en conséquence s’avére inutile et bloquant : par défaut, le contexte de sécurité appliqué est le plus restrictif et rend le compte inutilisable sur SELinux.

Le second est lié au montage des répertoires utilisateur via NFS : le patch supportant les attributs de sécurité de SELinux, encore expérimental, vient à peine de voir le jour. Ce patch n’est pas encore complètement fonctionnel et plus particulièrement dans le cas de notre étude de faisabilité sur le site du Loria : un espace NFS adressable de plus de trois téraoctets de données à gérer en terme de labélisation (enregistrement des contextes de sécurité sur les objets du système de fichier).

Outre le fait qu’il faille au préalable générer tous les attributs de sécurité sur tout cet es- pace, la simple gestion par un système SELinux sur noyau en version 2.4.X est impossible pour une raison évidente d’espace mémoire. En effet, les versions 2.4.X de SELinux enre- gistrent les données des contextes de sécurité dans une arborescente virtuelle gérée par le noyau, donc en mémoire vive. Or l’espace mémoire nécessaire dans le cas d’un pos- sible montage d’une partie de ces téraoctets de données est clairement insuffisant sur un simple poste de travail ou une station classique et pause à nouveau un problème bloquant. La gestion de ces même données de sécurité se fait différemment sur les noyaux de la série 2.6.X et est déportée sur les différents systèmes de fichier via la gestion par ceux-ci d’attributs avancés (support des Access Control Lists entre autre) disponibles sur les plus utilisés (ext2, ext3, reiserfs, XFS, etc.). Il faut alors activer le support de ces attributs sur tous les systèmes de fichier, puis les affecter, ce qui comme dans le cas précédant est un chantier à prévoir soigneusement pour un espace de données aussi conséquent. Et pour finir il faut, dans tous les cas, attendre un patch NFS suffisamment fonctionnel supportant l’une ou l’autre des deux méthodes présentées. À notre avis, si l’on doit utiliser SELinux de la sorte, autant se focaliser sur la seconde solution, prévue pour durer, car la première n’est qu’un portage en arrière sur les noyaux 2.4.X sans réel avenir. Et le passage en 2.6.X est une autre affaire...

5 ETUDE DE LA MISE EN ŒUVRE SUR MANDRAKE 30 5.5.4 Complexité de la mise en œuvre La complexité de mise en œuvre de cette solution sur une distribution Mandrake est suffisamment grande pour que personne jusqu’à présent ne s’y soit risqué, aucun support n’étant disponible pour celle-ci par son caractère plutôt orienté station de travail et les uti- lisateur final. Il est d’ailleurs mentionné, à plusieurs reprises et dans plusieurs sources documentaires relatives à SELinux, que celui-ci n’est pas destiné à être appliqué sur une station de travail mais sur un serveur. Et ce du fait de la complexité globale d’établissement d’une politique de sécurité cohérente pour l’ensemble d’un système. En ce qui concerne la problématique qui a été posée dans la mise en pratique de cette solution pour une machine d’accès au Loria, nous avons montré les difficultés relatives aux dépendances dues au service de comptes itinérants : à savoir une gestion correcte des “yellow pages” pour qu’elles véhiculent les contextes de sécurité des utilisateurs, la mise à jour de tous les systèmes de fichier des comptes des utilisateurs pour qu’ils sup- portent l’enregistrement des attributs de sécurité et l’utilisation d’une version “patchée” des démons NFS afin qu’ils offrent les accès nécessaires à ces informations de sécurité. Pour conclure sur la complexité de cette solution face au problème initial, on peut sou- ligner la dépendance lourde sur une infrastructure afférente qu’il sera coûteux de mettre en conformité et sûrement un choix très discutable de l’architecture et des besoins initia- lement évoqués. A notre avis, il n’y a pas de solution au problème posé qui ne soit pas complexe à partir du moment ou la machine “portail”, sécurisée par SELinux, doit fournir l’accès aux comptes itinérants. En se restreignant uniquement au principes de base d’une sécurité forte (ce qu’est censé fournir SELinux) on peut alors souligner une grave erreur de conception à la base. Pour ce qui est du choix de la distribution Mandrake, nous avons suffisamment développé la complexité de la mise en place de SELinuxsur ce système et n’en rajouterons pas plus.

5.6 Solutions préconisées La première des solutions consiste en fait à revoir l’idée du service envisagé. Faut-il fournir un accès distant complet aux ressources du Loria de la sorte ? N’est-il pas plus convenable d’établir un réseau privé virtuel directement, ou de virtualiser l’accès aux res- sources (duplication de la base d’authentification, séparation des accès aux données via une “passerelle”, etc.). De plus, qu’est-ce qui empêche aujourd’hui à un utilisateur d’utiliser la commande ssh, en interne, de manière très efficace avec l’option ’-R’ ? Une seconde solution, si vraiment la nécessité d’un tel accès au Loria est indispen- sable, c’est dans un premier temps de choisir une distribution supportant NSA SELinux et aussi supportée par la NSA et la communauté. Ensuite il convient, de dupliquer la base d’authentification pour des raison de sécurité (et de facilité : la propagation d’un compte de la première à la seconde n’est pas une difficulté en soit), d’interdire formellement tout accès sans clef SSH avec mot de passe et ainsi d’éviter le risque de piratage de cette même base : en bref utiliser un annuaire LDAP qui stocke les clefs SSH publiques mais

5 ETUDE DE LA MISE EN ŒUVRE SUR MANDRAKE 31 aucun mot de passe. Et aussi il faut prévoir un système de révocation rapide de ces accès (même depuis l’extérieur). Après si tous le monde doit pouvoir rebondir en interne via SSH, aucune restriction sur la première machine n’est bloquante pour l’utilisateur, il ne sert donc à rien de fournir tout sur la première machine : trop de compromis sur cette machine rend caduque tout effort de sécurité tant la complexité croit inexorablement avec chacun d’entre eux.

Donc pour finir, nous allons vous fournir une petite liste, non exhaustive, des princi- pales distributions pouvant convenir pour la mise en place d’un serveur sous système SELinux. Bien sûr, tout système Linux avec un noyau supportant SELinux et les bon outils conviendra mais, à moins de le réaliser vous-même et donc d’en avoir les moyens, nous vous invitons à suivre les quelques systèmes suivants, supportés non par la NSA qui officiellement n’en supporte aucune même si elle fourni tarballs et paquets pour la fedora mais par une communauté non négligeable d’utilisateurs : – RedHat fedora[4] : distribution largement supportée, surtout par des entreprises qui vendent un support, paquets disponibles directement sur le site de la NSA. – Gentoo[5] : distribution d’avant garde, avec un système de gestion de paquet puis- sant mais avec peu de règles de contrôle sur leur provenance et leur contenu, assez bien documentée en ce qui concerne SELinux.

– Debian[6] : de loin la distribution d’excellence pour les serveurs, une puissance d’administration encore inégalée en terme de gestion de paquet, de configuration et de mise à jour de sécurité. La documentation sur SELinux pour cette distribution est exemplaire, sa mise en œuvre est l’une des plus aisée. – Adamantix[7], basée sur Debian, elle intègre en standard un support de RSBAC, plus simple que SELinux, et plus encore.

– et nombre d’autres distributions, propriétaires pour la plupart, fournie avec des ap- plicatifs d’administration divers, sans aucun détail sur les politiques de sécurité de ces systèmes. Notre choix, si il fallait en faire un, serait une Debian ou directement une Adamantix (ex-TrustedDebian) si les services à sécuriser sont réduits au strict minimum.

6 CONCLUSION 32 6 Conclusion Ce projet nous a permis d’approfondir nos connaissances sur différentes méthodes vi- sant à sécuriser un système d’information de manière générale et un système informatique de manière particulière. Dans cette étude nous nous sommes particulièrement focalisé sur une approche, celle des accès mandatés mis en avant pas le noyau SELinux. Dans la partie application nous nous sommes trouvé confronté à de nombreux pro- blèmes qui, si ils ne nous ont pas permis d’aboutir sur cette partie, ils ont mis en exergue nombre des points sensibles de ce type de solution par accès mandaté. A la lumière de ceux-ci nous avons pu répondre de manière efficace aux contradictions de ce projet et pré- coniser non pas une alternative complète et viable, mais au moins des axes maintenant sûrement plus judicieux pour poursuivre plus en avant.

Nous tenons à remercier M Benjamin Deixheimer pour son soutien et son regard avisé tout au long de ce projet, ainsi que pour sa compréhension lorsque nous lui avons annoncé nos difficultés. Nous remercions aussi le personnel du Loria qui nous a accueilli dans ce petit espace de permanence pendant tout ce temps. Et, pour finir, nous remercions de manière anonyme les nombreux contributeurs au projet SELinux qui ont accepté de prendre un peu de leur temps pour éclairer nos lanternes.

TABLE DES FIGURES 33 Table des figures 1 Modèle général de sécurité . 5 2 RBAC basique . 6 3 preuve du principe de médiation . 14 4 preuve de l’autorisation . 15

RÉFÉRENCES 34 Références [1] Comment prouver la consistance des LSM . Using CQUAL for Static Analysis of Authorization Hook Placement . http://www.usenix.org/events/sec02/full_papers/zhang. 13 [2] L’outil utilisé pour faire ces preuves . http://www.cs.umd.edu/~jfoster/cqual/. 13 [3] Le site officiel de la NSA pour SELinux . http://www.nsa.gov/selinux/index.cfm. 27 [4] distribution SELinux pour redhat . http://www.fedora.redhat.com. 28, 31 [5] distribution SELinux pour gentoo . http://www.gentoo.org/proj/en/hardened/. 31 [6] distribution SELinux pour debian . http://www.coker.com.au/selinux. 31 [7] Une version amemiorée de SELinux, encore en open source . http://www.trusteddebian.org/. 31 [8] Le site de référence sur Sourceforge . Celui qui maintient la doc : Faye Coker, faye@lurking-grue.org . http://sourceforge.net/projects/selinux/.

[9] un hors série très complet pour tout comprendre . Linux Magazine HS 17 : Linux Security Modules. [10] Le site officiel des linux security modules . http://lsm.immunix.org. [11] Red hat on security : SELinux . http://www.redhat.com/solutions/security/SELinux.html. [12] distribution SELinux pour suze . http://www.leapster.org/linux/selinux/suse/.

Vous pouvez aussi lire