Table des matières

1 Introduction

Le modèle de contrôle d'accès discrétionnaire classiquement employé sur les systèmes GNU/Linux veut que l'ensemble des processus exécutés par le compte d'un utilisateur dispose des mêmes privilèges vis-à-vis des données auxquelles l'utilisateur a accès. En particulier, selon ce modèle, un programme légitime et un programme malveillant (résultant par exemple de l'exploitation d'une vulnérabilité au sein d'une application, ou d'une porte dérobée) disposent des mêmes droits. Ce modèle de contrôle d'accès est donc inadapté à une séparation des privilèges des applications en fonction de diérentes activités que peut avoir un utilisateur.

Les mécanismes de contrôle d'accès obligatoire (Mandatory Access Control), tels que SELinux ou AppArmor, visent notamment à pallier les limites du modèle de contrôle d'accès discrétionnaire (Discretionary Access Control), en permettant à l'administrateur d'appliquer une politique de sécurité globale sur le système, qui ane et restreint les permissions accordées aux programmes. Toutefois, cette politique de sécurité est appliquée de manière statique et s'avère complexe à élaborer en pratique.

Cet article présente StemJail, une solution qui permet de répondre au besoin de cloisonnement d'activités utilisateur de manière dynamique. Cette nouvelle approche du cloisonnement simplie l'utilisation du contrôle d'accès pour l'utilisateur. Notre preuve de concept permet de maîtriser les accès aux données utilisateur an d'éviter des fuites ou modications malveillantes, avec un impact négligeable sur les performances.

StemJail tire son nom des cellules souches (stem cells) capables de se multiplier mais surtout de se spécialiser. StemJail s'utilise sur un système GNU/Linux, sans modication intrusive, par des utilisateurs non privilégiés et en complément des contrôles d'accès déjà présents. L'intégralité du code source est disponible sur GitHub ¹ sous licence libre.

2 Objectif de sécurité et fonctionnalités de StemJail

Contrôle d'accès : StemJail fournit un contrôle d'accès complémentaire sur les données accessibles à l'utilisateur en fonction de son activité, ce qui permet d'améliorer leur protection en condentialité et en intégrité. L'utilisateur peut ainsi gérer les accès de ses instances d'applications en fonction de leur contexte d'utilisation. On s'intéresse uniquement au contrôle des accès légitimes pour le système aux chiers utilisateur, ce qui exclut par exemple les attaques sur la Trusted Computing Base (p. ex. noyau, services du système, matériel…) ou encore les attaques par canaux auxiliaires.

Fonctionnement adaptatif : Notre solution est capable de s'adapter aux changements d'activité utilisateur de manière dynamique.

Accessible à tout utilisateur : StemJail ore à chaque utilisateur du système le contrôle des accès à ses données, mais sans nécessiter de droits d'administration² .

3 Modèle de contrôle d'accès

3.1 Politique de sécurité dénie par l'utilisateur

Lorsque l'utilisateur est la source de l'information, nommée objet, il est le premier capable d'identier son niveau de condentialité. Il peut par exemple déterminer le caractère public ou privé d'une information, ou si elle relève de la sphère professionnelle ou personnelle. L'utilisateur va donc devoir dénir une politique de sécurité pour chacune de ses activités.

Chacune des instances d'application (c.-à-d. processus) d'un utilisateur est appelée sujet. On caractérise un domaine par un ensemble d'accès symbolisés par des triplets (sujet, action, objet) autorisés dans le cadre d'une activité. Les diérents domaines de la politique dénie par l'utilisateur sont appelés domaines naux.

3.2 Cloisonnement adaptatif par transition

Pour prendre en compte la politique congurée, on souhaite être capable d'inférer le domaine correspondant le mieux à l'activité en cours en fonction des droits d'accès de tous les domaines atteignables. Les recouvrements des domaines naux forment des intersections qu'on nomme domaines intermédiaires. Chaque domaine intermédiaire correspond donc à un sous-ensemble de domaines naux. An de respecter les droits d'accès aux données précédemment acquis, le type de transition envisageable consiste à transiter d'un domaine moins permissif vers un domaine plus permissif. Cette spécialisation de domaine permet donc de gagner des droits d'accès tout en respectant ceux du domaine source. L'objectif est qu'en conguration donnée, l'utilisateur n'ait pas d'action supplémentaire à eectuer pour que ses activités soient correctement prises en compte par la politique qu'il a initialement dénie. Ceci permet également d'éviter des oublis ou erreurs de l'utilisateur et de gagner en uidité.

La découverte d'une (future) activité commence donc par un domaine intermédiaire correspondant à un des sous-ensembles du domaine nal de cette activité. Au fur et à mesure des demandes d'accès faites par un sujet, le système peut être amené à faire transiter le domaine de ce sujet pour autoriser ses accès. Cette spécialisation du domaine est fonction des accès possibles et demandés (p. ex. demande d'ouverture d'un chier) par un sujet. On autorise donc des transitions d'un domaine intermédiaire vers un autre domaine (intermédiaire ou nal) seulement si le domaine destination inclut le domaine source. On s'assure ainsi de toujours respecter la politique d'accès dénie par un domaine nal, autrement dit, par l'utilisateur.

Les ensembles à gauche de la gure 1 représentent trois domaines naux : A, B et C. Chacun de ces domaines correspond à un ensemble d'accès qui peuvent être communs pour des domaines superposés. Les domaines intermédiaires respectifs sont ab, bc, ac et abc. Comme le montre le treillis à droite de la gure 1, il est possible de changer de domaine tant que le domaine destination contient le domaine source. Le déroulement du scénario de transitions par état de la gure 1 est le suivant :

1. Le premier état représente le domaine initial abc qui est l'intersection de trois domaines naux. Tous les domaines précédemment cités sont accessibles par transition, ce qui signie que le sujet qui y est présent dispose potentiellement des droits d'accès des domaines A, B et C. Le point symbolise un triplet (sujet;action;objet) correspondant à la demande du sujet.
2. Après une demande d'accès à une ressource uniquement accessible par le domaine A et B, an de pouvoir y accéder, le sujet transite vers le domaine ab. Dans le deuxième état, il est maintenant uniquement possible de transiter vers le domaine A ou B. Le système a donc déduit que l'activité n'était pas celle du domaine C. Toute demande d'accès à une ressource uniquement disponible dans le domaine C sera désormais refusée.
3. Enn, lors d'une demande d'accès vers une ressource uniquement accessible par le domaine B, le domaine du sujet se spécialise en B. Le domaine nal, troisième état, est maintenant atteint. Les accès précédemment accordés sont conservés mais il n'y a plus aucune transition possible. Durant toute la vie du sujet, tous les accès qui lui sont accordés sont donc ceux dénis par B ; c'est comme s'il avait toujours été dans B.

An que cette découverte de domaine fonctionne, il n'est pas nécessaire que tous les domaines aient un sous-ensemble commun. Il faut cependant que la demande d'accès initiale corresponde à un de ces sous-ensembles minimaux. Dans le cas contraire, les accès sont refusés. Les demandes suivantes seront traitées séquentiellement.

Dans le cas où les demandes d'accès ne peuvent pas être délivrées par un des domaines atteignables, elles sont simplement refusées. Le sujet reste alors dans son domaine intermédiaire jusqu'à ce qu'une autre demande d'accès puisse éventuellement le pousser dans un domaine qui se rapproche plus d'un domaine nal. La politique de sécurité dénie est bien respectée et permet de circonscrire au domaine de l'activité une éventuelle compromission. Les données dont l'accès n'est pas autorisé par ce domaine ne seront donc pas accessibles à l'attaquant.

4 Mise en uvre

An de permettre à chaque utilisateur de mettre en uvre des fonctionnalités de cloisonnement natives à GNU/Linux, StemJail tire parti des espaces de nom utilisateur (user namespaces), orant ainsi aux utilisateurs non-privilégié des fonctionnalités jusque là uniquement accessibles à l'administrateur de la machine. StemJail peut ainsi utiliser des bind mounts pour exposer les chiers autorisés à être visibles, accessibles en lecture-seule ou bien en lecture-écriture. Par ailleurs, l'utilisation de mécanismes de sécurité déjà présents sur le système évite d'en augmenter la surface d'attaque. StemJail est développé en Rust pour ses bonnes propriétés : un typage fort, de bonnes garanties sur l'utilisation de la mémoire (sans garbage collector) ou encore la gestion sûre de la concurrence.

Comme le montre la gure 2, l'architecture de StemJail est composée d'une instance de moniteur par domaine. Chaque moniteur gère son domaine et peut créer un nouveau domaine (avec un moniteur dédié) inclus dans son propre domaine. Ceci peut être utile dans un but de sécurité en profondeur par l'ajout de restrictions supplémentaires.

Les processus de chaque domaine peuvent communiquer par socket UNIX avec leur moniteur an de demander des droits d'accès supplémentaires. L'obtention de ces accès est eectuée par transition de domaine suivant les règles établies dans la section 3.2. Comme le montre la gure 3, nous dissocions la demande d'accès et l'accès eectif. Le client eectue d'abord une requête vers le moniteur pour demander l'accès à une ressource. Si la demande est légitime, contrairement au client, le moniteur est capable de faire évoluer le domaine avec une mise à jour des namespaces par le noyau. Enn, le client peut accéder à la ressource si le noyau le lui autorise.

An de s'intégrer dans les systèmes existants sans modication (statique) des applications, nous mettons en place des hooks sur certaines fonctions de la libc (p. ex. open) grâce à la fonctionnalité LD_PRELOAD (via un chier /etc/ld.so.preload dans chaque domaine). Cette approche a comme avantage de simplier le maintien des hooks sans aecter les mises à jour du système. De plus, l'impact sur les performances est négligeable par rapport à des techniques comme ptrace qui impliquent de nombreux changements de contexte. Étant donné que les décisions d'accorder les droits d'accès demandés ne sont pas prises par les clients mais bien par le moniteur puis vériées par le noyau, la sécurité du système ne repose donc absolument pas sur les hooks de la libc. Cette fonctionnalité permet cependant de rendre la majorité des programmes compatibles avec StemJail, le rendant utilisable dans des contextes concrets.

5 Conclusion

Nous avons présenté StemJail, une solution qui complète le contrôle d'accès existant en orant la capacité à chaque utilisateur de maîtriser, par activité, les accès à ses données. La prise en compte des autres ressources du système (p. ex. réseau) est en cours. La conception d'une IHM de conance prenant en compte les domaines des processus, an de permettre aux utilisateurs de les distinguer, fait également partie des travaux futurs.