Sécurité basée sur les capacités

La sécurité basée sur les capacités est un concept fondamental de la conception des systèmes informatiques sécurisés , et constitue l'un des modèles de sécurité existants . Une capacité (appelée clé dans certains systèmes ) est un jeton d'autorisation communicable et infalsifiable. Elle désigne une valeur qui référence un objet et un ensemble de droits d'accès associés . Un programme utilisateur sur un système d'exploitation basé sur les capacités doit utiliser une capacité pour accéder à un objet. La sécurité basée sur les capacités repose sur le principe de conception des programmes utilisateurs de manière à ce qu'ils partagent directement leurs capacités selon le principe du moindre privilège , ainsi que sur l'infrastructure du système d'exploitation nécessaire pour garantir l'efficacité et la sécurité de ces transactions. La sécurité basée sur les capacités s'oppose à l'approche traditionnelle utilisant les permissions UNIX et les listes de contrôle d'accès .

Bien que la plupart des systèmes d'exploitation implémentent un mécanisme similaire aux capacités, ils n'offrent généralement pas un support suffisant pour permettre à l'échange de capacités entre entités potentiellement méfiantes de constituer le principal moyen d'octroi et de distribution des droits d'accès au sein du système. Un système basé sur les capacités, en revanche, est conçu dans cette optique.

Une capacité est généralement implémentée comme une structure de données privilégiée comprenant une section spécifiant les droits d'accès et une autre identifiant de manière unique l'objet à accéder. L'utilisateur n'accède pas directement à la structure de données ni à l'objet, mais via un descripteur . En pratique, ce descripteur est utilisé de manière similaire à un descripteur de fichier dans un système d'exploitation classique, mais pour accéder à n'importe quel objet du système. Les capacités sont généralement stockées par le système d'exploitation dans une liste, avec un mécanisme empêchant le programme de modifier directement leur contenu (afin de falsifier les droits d'accès ou de modifier l'objet pointé). Certains systèmes, comme le Plessey System 250 , reposent également sur l'adressage par capacité (prise en charge matérielle des capacités).

Les programmes disposant de capacités peuvent effectuer des opérations sur ces capacités, comme les transmettre à d'autres programmes, les convertir en une version moins privilégiée ou les supprimer. Le système d'exploitation doit garantir que seules certaines opérations spécifiques puissent être effectuées sur les capacités du système, afin de préserver l'intégrité de la politique de sécurité.

Les capacités décrites dans cet article ne doivent pas être confondues avec les « capacités » de l’interface POSIX 1e/2c . Ces dernières correspondent à des privilèges généraux qui ne peuvent être transférés entre processus.

Une capacité est définie comme une référence d'objet protégée qui, du fait de sa possession par un processus utilisateur, confère à ce processus la capacité (d'où son nom) d'interagir avec un objet de certaines manières. Ces manières peuvent inclure la lecture des données associées à un objet, la modification de l'objet, l'exécution des données de l'objet en tant que processus, et d'autres droits d'accès concevables. Logiquement, la capacité se compose d'une référence qui identifie de manière unique un objet particulier et d'un ensemble d'un ou plusieurs de ces droits.

Supposons que, dans l'espace mémoire d'un processus utilisateur, il existe la chaîne de caractères suivante :

/etc/passwd

Bien que cela identifie un objet unique sur le système, cela ne spécifie pas les droits d'accès et ne constitue donc pas une capacité. Supposons plutôt la paire de valeurs suivante :

/etc/passwd O_RDWR

Cette paire identifie un objet ainsi qu'un ensemble de droits d'accès. Cependant, elle ne constitue pas encore une capacité, car la possession de ces valeurs par le processus utilisateur ne renseigne en rien sur la légitimité de cet accès.

Supposons maintenant que le programme utilisateur exécute avec succès l'instruction suivante :

La variable fdcontient désormais l'index d'un descripteur de fichier dans la table des descripteurs de fichiers du processus. Ce descripteur de fichier constitue une capacité. Sa présence dans la table des descripteurs de fichiers du processus suffit à démontrer que ce dernier dispose bien d'un accès légitime à l'objet. Une caractéristique essentielle de ce système est que la table des descripteurs de fichiers réside en mémoire noyau et ne peut être manipulée directement par le programme utilisateur.

Dans les systèmes d'exploitation traditionnels, les programmes communiquent souvent entre eux et avec le stockage à l'aide de références similaires à celles des deux premiers exemples. Les chemins d'accès sont fréquemment transmis comme paramètres de ligne de commande, envoyés via des sockets et stockés sur disque. Ces références ne constituent pas des capacités et doivent être validées avant utilisation. Dans ces systèmes, une question centrale se pose : « De quelle autorité une référence donnée doit-elle être évaluée ? » Ce point devient crucial, notamment pour les processus agissant pour le compte de deux entités d'autorité différentes. Ils deviennent alors vulnérables à une erreur de programmation connue sous le nom de problème du délégué confus , qui engendre très souvent une faille de sécurité .

Dans un système basé sur les capacités, les capacités elles-mêmes sont transmises entre les processus et le stockage à l'aide d'un mécanisme reconnu par le système d'exploitation pour maintenir l'intégrité de ces capacités.

Une approche novatrice pour résoudre ce problème consiste à utiliser un système d'exploitation à persistance orthogonale . Dans un tel système, il n'est pas nécessaire de supprimer des entités ni d'invalider leurs capacités, et donc de recourir à un mécanisme de type ACL pour les restaurer ultérieurement. Le système d'exploitation garantit en permanence l'intégrité et la sécurité des capacités stockées, qu'elles soient volatiles ou non, notamment en effectuant lui-même toutes les tâches de sérialisation , contrairement à la plupart des systèmes d'exploitation qui s'en chargent. Déchargés de cette responsabilité, les programmes utilisateurs n'ont plus besoin de s'assurer qu'ils reproduisent uniquement les capacités autorisées, ni de valider les demandes d'accès par un mécanisme de contrôle d'accès . La machine Flex, datant du début des années 1980, en est un exemple .

La norme POSIX (Portable Operating System Interface) 1003.1e définit un concept de permissions appelé « capacités ». Cependant, les capacités POSIX diffèrent de celles abordées dans cet article. Une capacité POSIX n'est associée à aucun objet ; un processus possédant la capacité CAP_NET_BIND_SERVICE peut écouter sur n'importe quel port TCP inférieur ou égal à 1024. Ce système est présent dans Linux.

À l'inverse, Capsicum Unix combine un véritable modèle de système de capacités avec une architecture Unix et une API POSIX. Les capacités Capsicum constituent une forme améliorée de descripteur de fichier, un droit délégable entre processus. Des types d'objets supplémentaires, au-delà de POSIX classique, tels que les processus, peuvent être référencés via les capacités. En mode de capacité Capsicum, les processus ne peuvent pas utiliser les espaces de noms globaux (comme l'espace de noms du système de fichiers) pour rechercher des objets ; ils doivent les hériter ou se les voir déléguer. Ce système est présent nativement dans FreeBSD, mais des correctifs sont disponibles pour d'autres systèmes.

Parmi les systèmes de recherche et commerciaux notables utilisant une sécurité basée sur les capacités, on peut citer les suivants :

• Tahoe-LAFS , un système de fichiers open source basé sur les capacités
• FreeBSD Capsicum
• Génode
• Fuchsia
• HarmonyOS ( OpenHarmony )
• Phantom OS
• RedoxOS
• Famille de micro-noyaux L4 :
  • OKL4 d'Open Kernel Labs
  • seL4 de NICTA
  • Fiasco.OC et NOVA de l'Université technique de Dresde
• Interface système WebAssembly (WASI)