Protection, isolation et machines virtuelles

Un programme a besoin d’assez de liberté pour calculer rapidement sans prendre le contrôle de tout l’ordinateur. Le mode utilisateur lui permet d’exécuter directement les instructions ordinaires. Le mode noyau, aussi appelé mode superviseur, donne au système d’exploitation accès aux instructions qui contrôlent la machine.

Laisse le matériel faire respecter les privilèges

Le processeur possède un niveau de privilège courant. Les additions, chargements, écritures et sauts s’exécutent normalement à pleine vitesse, sous réserve des permissions mémoire. Le noyau n’examine pas chaque instruction par logiciel. C’est l’exécution directe limitée : les instructions s’exécutent directement jusqu’à ce qu’une opération protégée ou une interruption nécessite l’intervention du noyau.

Une instruction privilégiée provoque un déroutement si le code utilisateur tente de l’exécuter. Sur x86-64, HLT, l’écriture dans le registre de base de la table des pages CR3 et l’installation d’une table des interruptions avec LIDT exigent les privilèges du noyau. Sinon, une application pourrait arrêter le processeur, remplacer ses propres limites mémoire ou rediriger le traitement des interruptions.

Supposons qu’une application exécute HLT. Le processeur déclenche une exception de protection générale au lieu de s’arrêter. Il entre dans le gestionnaire enregistré par le noyau. Linux envoie normalement SIGSEGV au processus, ce qui le termine tandis que les autres programmes continuent. L’application ne peut pas choisir une adresse qui lui convient dans le noyau et commencer à y exécuter du code.

Franchis la frontière par une entrée contrôlée

Les déroutements, exceptions et interruptions entrent par des adresses enregistrées par le noyau. Le matériel change le niveau de privilège et transmet le contrôle au gestionnaire ; le code d’entrée du noyau conserve l’état nécessaire au retour. Une instruction de retour spéciale reprend l’exécution en mode utilisateur au compteur ordinal sauvegardé. Sur x86-64, le retour peut utiliser SYSRET ou IRETQ.

L’horloge rend ce contrôle utile même lorsqu’un programme ne demande jamais de service. Avant de l’exécuter, le noyau programme une horloge. Lorsque l’interruption arrive, l’ordonnanceur peut choisir un autre processus. Le code utilisateur ne peut pas désactiver les interruptions ni reprogrammer cette horloge : une boucle sans fin ne peut donc pas conserver un cœur indéfiniment.

Lis correctement les schémas de privilèges

Les conventions de numérotation diffèrent : un numéro d’anneau x86 plus faible signifie davantage de privilèges, tandis qu’un niveau d’exception ARM plus élevé signifie davantage de privilèges. La virtualisation Intel ajoute aussi les modes VMX root et non-root ; ils sont distincts du numéro d’anneau.

Distingue l’identité du mode du processeur

Root est une identité d’utilisateur, UID 0, que le logiciel du noyau reconnaît. Le code ordinaire d’une application root s’exécute toujours en mode utilisateur et entre dans le noyau par des appels système. Un pilote de périphérique exécuté en mode noyau dispose d’un pouvoir direct bien plus important : un bogue mémoire à cet endroit peut endommager l’état du noyau sans passer par une vérification des permissions de fichier.

La couche qui fait respecter une frontière doit contrôler la couche située à l’intérieur. Le noyau fait respecter les frontières entre processus à l’aide des modes du processeur et des tables mémoire. De même, un hyperviseur contrôle les systèmes d’exploitation invités grâce à la prise en charge matérielle de la virtualisation.

Un appel système est une demande contrôlée adressée au noyau pour obtenir un service. Ouvrir des fichiers, créer des processus et envoyer des données sur le réseau exigent des décisions qu’une application ne peut pas prendre elle-même en toute sécurité. L’entrée dans le noyau donne de l’autorité au gestionnaire ; elle ne donne pas à l’appelant la permission de faire tout ce qu’il a demandé.

Suis la demande

Une fonction d’enveloppe de la bibliothèque C telle que open() place le numéro de l’appel et ses arguments dans des registres. Elle utilise SYSCALL sur x86-64, SVC sur ARM64 ou ECALL sur RISC-V. Le noyau :

1. Entre par son point d’entrée enregistré et sauvegarde les registres utilisateur.
2. Choisit le gestionnaire dans la table des appels système et rejette tout numéro inconnu.
3. Lit l’identité et les identifiants de l’appelant dans le processus courant.
4. Vérifie les arguments, les droits d’accès et les objets concernés.
5. Effectue l’opération ou renvoie une erreur.
6. Restaure l’état sauvegardé et revient en mode utilisateur.

L’identité provient des identifiants du processus, et non d’un nom fourni par l’utilisateur. Un appelant ne peut pas obtenir les droits d’un autre utilisateur en ajoutant le nom de celui-ci à une demande.

Considère les arguments comme non fiables

Un pointeur n’est qu’un nombre fourni par l’appelant. Le noyau doit vérifier toute la zone de mémoire utilisateur demandée, y compris sa longueur et le sens de l’accès. Linux utilise des routines qui effectuent des vérifications, telles que copy_from_user et copy_to_user, pour franchir cette frontière en toute sécurité.

Pour read(fd, buf, 4096), un buf qui pointe dans la mémoire du noyau ne doit pas devenir une destination pour les données du fichier. Linux signale EFAULT pour ce tampon utilisateur invalide. Une autre erreur a une autre cause : write() sur un descripteur ouvert avec O_RDONLY échoue avec EBADF, car le droit d’écriture n’a jamais été accordé à ce descripteur. Une demande ordinaire refusée renvoie une erreur ; elle ne termine pas automatiquement le processus. En C, la fonction d’enveloppe renvoie généralement −1 et définit errno.

Vérifie l’objet réellement utilisé

Une condition de concurrence entre vérification et utilisation (TOCTTOU) sépare une décision de l’objet qu’elle devait protéger. Un programme auxiliaire privilégié vérifie access("/tmp/report", W_OK), puis ouvre le chemin. Entre ces opérations, un attaquant remplace le chemin par un lien symbolique vers /etc/passwd. Le nom ne change pas, mais l’objet ouvert est différent.

La correction consiste à effectuer l’accès avec les identifiants prévus sur l’objet réellement ouvert. Abandonne les privilèges avant l’ouverture et utilise des options telles que O_NOFOLLOW lorsque les liens symboliques ne sont pas souhaités. Copier une seule fois les arguments en mémoire noyau évite aussi de faire confiance à plusieurs reprises à des données utilisateur modifiables ; la structure copiée doit toutefois être validée.

Identifie ce qui doit être fiable

Un moniteur de référence contrôle les accès. Il doit être invoqué chaque fois qu’un accès est obtenu, être protégé contre les modifications et être assez petit pour être examiné soigneusement. Une fois que le noyau a accordé une projection mémoire, chaque lecture et chaque écriture passe par les vérifications de permissions de la MMU ; chacune ne déclenche pas un appel système.

La base informatique de confiance (TCB) comprend le matériel, le micrologiciel et les logiciels privilégiés dont le bon fonctionnement conditionne la protection. Elle inclut le processeur, la chaîne de démarrage, le noyau et les composants de connexion de confiance. Déplacer les pilotes ou les systèmes de fichiers dans des serveurs en mode utilisateur peut réduire la partie de cette base située dans le noyau, comme le font les architectures à micronoyau. Une application ordinaire compromise utilise à mauvais escient les droits qui lui ont été accordés ; un composant de confiance compromis peut affaiblir les vérifications elles-mêmes.

La mémoire virtuelle protège les programmes en plus de traduire les adresses. Un processus peut atteindre les cadres physiques désignés par sa table des pages active, selon les permissions définies par le noyau. Les cadres privés d’un autre processus en sont absents ; les projections volontaires de mémoire partagée constituent une exception explicite.

Vérifie chaque accès mémoire

L’unité de gestion mémoire (MMU) vérifie les entrées de table des pages lors des accès. Parmi les permissions importantes figurent la présence ou validité, l’autorisation d’écriture, l’accès en mode utilisateur et l’exécution. Sur x86, U/S distingue les pages accessibles en mode utilisateur de celles réservées au superviseur ; NX ou XD désactive l’exécution. ARM appelle XN sa restriction d’exécution.

Une violation déclenche un défaut de page. Le défaut indique l’échec d’une vérification matérielle ; le noyau détermine si cet échec est attendu et peut être corrigé. Considérons deux écritures dans des pages en lecture seule :

• Un processus écrase une page de code qui n’est pas en copie sur écriture. Le noyau traite cela comme une écriture invalide et envoie normalement SIGSEGV.
• Après fork(), un processus écrit dans des données partagées marquées en copie sur écriture. Le noyau alloue une copie privée, modifie la projection pour y autoriser l’écriture et réessaie l’instruction.

Les deux défauts proviennent d’un bit de protection. Les informations du noyau expliquent pourquoi les projections étaient en lecture seule et déterminent la réponse. Un défaut de page n’est donc pas automatiquement une panne ni une demande de lecture de données sur disque.

Protège les projections du noyau dans les deux sens

Les organisations traditionnelles projettent la mémoire du noyau dans les espaces d’adressage des processus en la réservant au superviseur, ce qui facilite l’entrée dans le noyau tout en bloquant les lectures et écritures en mode utilisateur. L’attaque Meltdown de 2018 a montré que certains processeurs pouvaient divulguer de telles données par l’exécution spéculative. L’isolation des tables des pages du noyau (KPTI) retire la plupart des projections du noyau pendant l’exécution du code utilisateur sur les systèmes concernés.

Le code noyau doit aussi être protégé contre une redirection vers une mémoire contrôlée par l’utilisateur. Sur x86, SMEP empêche l’exécution en mode noyau depuis des pages utilisateur. SMAP bloque les accès aux données des pages utilisateur en mode noyau, sauf pendant des opérations de copie explicitement autorisées. ARM fournit des protections apparentées avec PXN et PAN. Ces vérifications réduisent les possibilités pour un attaquant d’exploiter un bogue du noyau afin d’exécuter du code ou de fournir de fausses données au noyau.

L’accès en lecture seule protège l’intégrité, pas le secret. Si un processus peut lire une page projetée, il peut en connaître le contenu même lorsque les écritures échouent. Les données confidentielles doivent être inaccessibles à ce processus : ne les projette pas ou applique une restriction appropriée au superviseur.

Donne aux périphériques leur propre frontière

Les applications demandent généralement à un pilote d’effectuer des opérations sur un périphérique. Les registres des périphériques sont normalement réservés au noyau, même si un processus autorisé peut recevoir certaines projections, comme avec les pilotes graphiques ou les entrées-sorties Linux en espace utilisateur.

Un périphérique qui effectue un accès direct à la mémoire (DMA) lit ou écrit dans la mémoire vive sans faire passer ces accès par la MMU du processeur. Les seules permissions de page du processeur ne peuvent pas empêcher un périphérique défectueux d’écraser les cadres d’un autre processus. Une IOMMU traduit et limite les adresses des périphériques à l’aide de projections propres à chacun. Intel VT-d et AMD-Vi fournissent ce mécanisme.

Pour un périphérique attribué à une machine virtuelle, l’IOMMU limite le DMA à la mémoire attribuée à cette machine. Le processeur a besoin d’une frontière parallèle : une seconde étape de traduction des pages associe les adresses physiques de l’invité uniquement aux cadres autorisés par l’hyperviseur. Protéger une charge de travail exige de couvrir à la fois les accès du processeur et ceux des périphériques.

Un bogue de sûreté mémoire peut donner lieu à une attaque lorsque des données corrompues modifient le flot de contrôle du programme. Un débordement de tampon sur la pile, par exemple, peut écraser une adresse de retour sauvegardée. Les défenses du système d’exploitation limitent ce qu’un attaquant peut faire avec ce bogue ; elles ne corrigent pas l’écriture fautive.

Sépare les données du code exécutable

Le bit NX marque les pages de données comme non exécutables. Windows appelle cela Data Execution Prevention (DEP). Injecter des instructions dans un tampon de la pile est moins utile lorsqu’un saut vers ce tampon provoque un défaut.

W^X, écriture ou exécution exclusive, est plus strict : aucune page n’est accessible en écriture et exécutable en même temps. DEP seul n’interdit pas à un programme de demander explicitement une telle projection. Avec W^X, un compilateur à la volée écrit le code généré dans une mémoire accessible en écriture, puis modifie ses permissions avant de l’exécuter.

Un attaquant peut aussi réutiliser des instructions exécutables existantes. La programmation orientée retour (ROP) enchaîne de courtes séquences d’instructions appelées gadgets. La randomisation de l’espace d’adressage (ASLR) change les emplacements des piles, des tas, des bibliothèques et des programmes indépendants de leur position, ce qui rend les adresses des gadgets difficiles à prévoir.

Avec une base de bibliothèque choisie uniformément parmi $2^{28}$ emplacements, une tentative à l’aveugle réussit avec une probabilité de 1 sur 268 435 456. Avec seulement $2^8=256$ emplacements et une disposition conservée après les pannes des processus travailleurs, essayer des emplacements distincts nécessite au plus 256 tentatives et 128,5 en moyenne. Une adresse divulguée à l’intérieur d’une bibliothèque connue révèle sa base et les déplacements des gadgets dans cette bibliothèque. Une pile randomisée séparément peut toutefois rester inconnue.

Réduis les services qu’un attaquant peut demander

Les filtres seccomp de Linux limitent les appels système qu’un processus peut effectuer. Un processus de rendu de navigateur, par exemple, peut se voir refuser les appels permettant de lancer des programmes ou d’ouvrir directement des fichiers. Les processus fils héritent des filtres, qui ne peuvent pas être retirés ; des filtres ultérieurs peuvent renforcer les restrictions. Un processus de rendu compromis conserve les opérations qui lui sont autorisées : un filtre constitue donc une frontière autour des services, et non une preuve que le programme est exempt de bogues. pledge d’OpenBSD et App Sandbox de macOS fournissent des restrictions apparentées.

Vérifie le démarrage et conserve les preuves

Le démarrage sécurisé vérifie les signatures tout au long de la chaîne de démarrage. Le micrologiciel vérifie un chargeur de démarrage de confiance ; le chargeur vérifie le noyau ; le noyau peut exiger des modules signés. Un composant modifié sans signature reconnue comme fiable est refusé. Cela aide à empêcher les modifications persistantes des logiciels de démarrage, mais une signature valide ne prouve pas que le logiciel est exempt de vulnérabilités.

Le démarrage mesuré enregistre les empreintes des composants chargés, généralement à l’aide d’un module de plateforme sécurisée (TPM). Ces mesures permettent une attestation : un tiers peut comparer ce qui a démarré à un état attendu. Mesurer et refuser de démarrer sont deux opérations différentes.

La journalisation d’audit enregistre les connexions, les échecs d’authentification, les refus de permission, les modifications de comptes et les actions privilégiées telles que sudo. Les journaux facilitent la détection et la reconstitution. Un attaquant qui contrôle un hôte peut effacer les enregistrements locaux ; une journalisation protégée ou distante permet donc de conserver des preuves ailleurs que sur cet hôte.

Les attaquants peuvent combiner une fuite d’adresse, un bogue de corruption mémoire et une évasion de bac à sable. Les mises à jour suppriment les vulnérabilités sous-jacentes que ces défenses laissent en place.

Une connexion réussie associe l’identité d’une personne aux identifiants de processus détenus par le noyau. L’authentification vérifie l’identité déclarée ; l’autorisation détermine ce que cette identité peut faire. Un principal peut être une personne ou un compte de service, et les processus agissent pour son compte.

Transmets l’identité aux programmes en cours d’exécution

Les systèmes de type Unix identifient les utilisateurs par des UID numériques et les groupes par des GID. /etc/passwd associe les noms aux UID, aux répertoires personnels et aux interpréteurs de commandes. Les comparaisons du noyau utilisent les nombres : deux noms de compte ayant un même UID représentent une seule identité pour les vérifications d’accès. L’UID 0 est celui de root et contourne la plupart des vérifications ordinaires de permissions.

Windows utilise des identifiants de sécurité (SID) pour les utilisateurs et les groupes. Le jeton d’accès d’un processus enregistre son SID utilisateur, ses SID de groupe et ses privilèges. Sur les deux plateformes, les identifiants du programme en cours d’exécution fournissent l’identité utilisée pour les décisions ultérieures.

Une connexion Linux typique par mot de passe suit cette séquence :

1. Un service de connexion privilégié, tel que login, sshd ou un gestionnaire de connexion graphique, reçoit les identifiants.
2. PAM les vérifie par l’intermédiaire des modules d’authentification configurés.
3. Le service définit les groupes supplémentaires et le GID de l’utilisateur, puis change l’UID pour abandonner les privilèges root.
4. Il lance l’interpréteur de commandes. Les processus fils héritent de ces identifiants par fork() et les conservent normalement après execve().

L’ordre compte. Abandonner les privilèges root avant de définir les groupes peut empêcher le processus de remplacer la liste de groupes privilégiés dont il a hérité. De plus, modifier l’appartenance d’un compte à des groupes ne réécrit pas les identifiants des processus déjà en cours d’exécution ; une nouvelle session de connexion reçoit la nouvelle liste.

Comprends un changement de privilège contrôlé

Un processus possède un UID réel, qui indique normalement qui l’a lancé ; un UID effectif, utilisé pour la plupart des vérifications d’accès ; et un UID sauvegardé, qui permet un retour contrôlé après une réduction temporaire. Dans les programmes ordinaires, les trois sont égaux.

Le fichier /usr/bin/passwd, qui appartient à root, illustre setuid. Son mode 4755, affiché -rwsr-xr-x, donne l’UID effectif de root lorsqu’un utilisateur ordinaire l’exécute. Si alice a l’UID 1000, son UID réel reste 1000 tandis que l’UID effectif devient 0. Le programme peut mettre à jour /etc/shadow et utilise l’identité réelle de l’appelant pour limiter les mots de passe qu’il peut modifier. Un exécutable setgid modifie de la même façon le groupe effectif.

Ce petit programme de confiance détient un pouvoir dangereux. Un bogue peut exposer les droits root : les systèmes limitent donc le nombre de programmes setuid et abandonnent les privilèges dès que possible. Pour un service qui n’a besoin que d’un port de numéro inférieur, CAP_NET_BIND_SERVICE accorde un privilège Linux plus limité que les droits root complets.

Administre sans partager une identité

sudo authentifie l’utilisateur qui l’invoque, vérifie quelles commandes il peut exécuter sous quelle identité cible et journalise l’utilisation. Sa politique se trouve généralement dans /etc/sudoers. Les identités individuelles permettent d’attribuer les actions à chaque personne, ce que le partage d’un mot de passe root ne permet plus. Sous Windows, UAC lance normalement les programmes d’un administrateur avec un jeton filtré et demande son accord pour l’élévation des privilèges.

Les applications courantes devraient s’exécuter avec des droits ordinaires et les services devraient disposer de comptes dédiés tels que www-data. Un lecteur de documents compromis hérite alors de ces identifiants limités au lieu des pleins pouvoirs d’un administrateur.

Un système de vérification des mots de passe doit reconnaître un mot de passe correct sans en stocker une copie récupérable. Il stocke une empreinte de mot de passe avec les informations nécessaires pour répéter la vérification. Lors de la connexion, il recalcule l’empreinte à partir du mot de passe saisi et compare les résultats ; il ne déchiffre jamais l’empreinte stockée.

Protège les données de vérification stockées

Sous Linux, /etc/shadow contient les empreintes de mots de passe protégées. Le fichier /etc/passwd, lisible par un grand nombre d’utilisateurs, contient les informations des comptes et un x à la place du mot de passe. Un champ de mot de passe de shadow enregistre un identifiant d’algorithme, des paramètres de coût, un sel et l’empreinte obtenue. $y$ désigne yescrypt, utilisé par défaut dans Debian 11, Ubuntu 22.04, Fedora 35 et les versions ultérieures ; $6$ désigne SHA-512-crypt.

Un fichier d’empreintes volé permet une attaque hors ligne. L’attaquant calcule les empreintes de ses propositions sur un autre matériel, sans subir les délais du service de connexion. Une attaque par force brute énumère les chaînes ; une attaque par dictionnaire commence par les mots probables, les mots de passe divulgués et des variantes telles que « Password1! ».

Avec exactement huit lettres minuscules, ${26}^8=208827064576$ chaînes sont possibles. À ${10}^{10}$ essais par seconde, parcourir tout l’espace prend environ 21 secondes. À ${10}^4$ essais par seconde, cela prend environ $\mathrm{2,09}\times {10}^7$ secondes, soit à peu près 242 jours. Ce sont des durées de recherche exhaustive, pas des garanties pour un mot de passe donné. Douze lettres minuscules donnent environ $\mathrm{9,5}\times {10}^{16}$ chaînes, soit à peu près 110 jours même au débit le plus élevé.

Rends l’attaque de chaque compte coûteuse

Un sel est une nouvelle valeur aléatoire stockée à côté de chaque empreinte de mot de passe. Il fait produire des empreintes différentes à des mots de passe identiques et rend inutilisables les tables précalculées réutilisables. Le sel est public ; son rôle est d’imposer un travail distinct pour chaque compte.

Considérons 1 000 comptes et une liste de ${10}^6$ propositions, vérifiées à raison de ${10}^4$ calculs d’empreinte par seconde. Sans sel, calculer une fois les empreintes de la liste prend 100 secondes et suffit pour tous les comptes. Des sels uniques exigent ${10}^9$ calculs, soit environ ${10}^5$ secondes ou 27,8 heures. Un mot de passe courant peut toutefois être trouvé près du début de la liste.

Les méthodes de hachage des mots de passe telles que bcrypt, scrypt, yescrypt, Argon2 et PBKDF2 ont des coûts de calcul réglables. Scrypt, yescrypt et Argon2 imposent aussi des coûts en mémoire. Une connexion pratique peut tolérer une fraction de seconde ; une vaste campagne d’essais répète ce coût des millions de fois. Un seul calcul SHA-256 rapide ne présente pas ce coût délibéré.

Conçois la politique de connexion autour des essais

NIST SP 800-63B-4 (2025) exige des sels d’au moins 32 bits et un coût de hachage des mots de passe aussi élevé que possible en pratique. Ses recommandations exigent au moins 15 caractères pour une authentification par mot de passe seul, ou au moins huit lorsque le mot de passe fait partie d’une authentification multifacteur, et recommandent d’accepter au moins 64 caractères.

Elles rejettent les mélanges obligatoires tels qu’un chiffre et un symbole ainsi que les changements de mot de passe périodiques imposés. Elles exigent de bloquer les choix courants ou compromis, de limiter les essais en ligne et d’imposer un changement lorsque la compromission est avérée. Les limites de débit en ligne protègent le service actif ; un hachage lent avec sel protège les données de vérification volées. Un mot de passe plus long choisi de manière prévisible dans une liste courante peut rester faible.

Les mots de passe prouvent une connaissance. D’autres authentificateurs prouvent la possession d’un objet ou une caractéristique physique. Le système d’exploitation finit par associer l’identité authentifiée aux processus, mais la manière d’établir cette identité influe sur la facilité avec laquelle un attaquant peut usurper l’identité de l’utilisateur.

Combine différents types de facteurs

Les trois types de facteurs sont ce que tu sais, comme un mot de passe ou un code PIN ; ce que tu possèdes, comme un téléphone, une carte à puce ou une clé de sécurité ; et ce que tu es, comme une empreinte digitale. L’authentification multifacteur combine des types différents. Un mot de passe associé à une question de sécurité répète le facteur de connaissance.

Les mots de passe à usage unique fondés sur le temps (TOTP) utilisent un secret partagé et une période, généralement de 30 secondes, pour produire des codes correspondants sur un authentificateur et un serveur. La RFC 6238 définit cette méthode. Un code expire rapidement, mais une fausse page de connexion peut transmettre un code récent avant son expiration. Les codes d’application évitent l’échange de carte SIM ; les codes SMS dépendent du contrôle du numéro de téléphone et peuvent être détournés si celui-ci est compromis.

Prouve la possession sans envoyer la clé

Un authentificateur à clé publique signe un nouveau défi avec une clé privée. Le serveur vérifie la signature à l’aide d’une clé publique stockée, qui ne peut pas elle-même être réutilisée pour signer une connexion. Les clés de sécurité FIDO2 et les clés d’accès associent aussi l’authentification à l’identité du site : une réponse destinée à un faux site ne peut donc pas authentifier l’utilisateur sur le vrai. Une clé SSH ordinaire prouve aussi la possession, mais il ne faut pas supposer qu’elle dispose du même mécanisme de liaison au site web.

Le stockage modifie le risque. Les clés liées à un appareil, dans une clé de sécurité matérielle, un TPM ou une enclave sécurisée, signent dans le matériel sans exposer la clé privée. Les clés d’accès synchronisées copient les éléments de clé chiffrés entre les appareils par l’intermédiaire d’un compte de plateforme, ce qui facilite la récupération tout en intégrant ce compte à la frontière de confiance. Une clé privée SSH ordinaire est un fichier protégé par des permissions et, éventuellement, une phrase secrète.

Interprète les erreurs biométriques

Un système biométrique compare les traits mesurés à un gabarit enregistré. Il accepte lorsque le score de similarité atteint un seuil ; il n’exige pas une image identique à chaque fois.

Deux imposteurs acceptés sur 10 000 donnent un FAR de 0,02 %. Trente rejets sur 1 000 tentatives légitimes donnent un FRR de 3 %. Relever le seuil de similarité diminue le FAR tout en augmentant le FRR. Une correspondance plus exigeante réduit les usurpations réussies, mais rend les nouvelles tentatives légitimes plus fréquentes.

Une caractéristique biométrique divulguée ne peut pas être changée comme un mot de passe, et les capteurs ont besoin de protections contre les photos ou les empreintes copiées. Une conception utile emploie la biométrie localement pour déverrouiller une clé protégée et n’envoie qu’une signature au serveur.

Authentifie aussi les processus

Pour une connexion locale de domaine Unix, SO_PEERCRED sous Linux obtient les identifiants du processus distant auprès du noyau au lieu de faire confiance à un nom envoyé par le client. Entre machines, les services utilisent des clés, des certificats ou des jetons stockés avec un accès réservé au compte de service. Après la connexion, les vérifications d’accès ordinaires du système d’exploitation utilisent l’UID ou le jeton d’accès ; elles ne demandent pas si l’utilisateur a saisi un mot de passe ou touché une clé.

Une décision d’accès comporte trois éléments : un sujet demande à effectuer une opération sur un objet. Le sujet est généralement un processus agissant pour un principal ; les objets comprennent les fichiers, les périphériques et les autres processus. Une matrice d’accès représente les droits dans des cases, avec les sujets en lignes et les objets en colonnes.

Stocke les mêmes droits de deux façons

Supposons qu’alice puisse lire et modifier report.txt, que bob puisse seulement le lire et que le service de sauvegarde puisse lire à la fois report.txt et payroll.db. Bob peut aussi lire et modifier payroll.db. Alice et bob peuvent utiliser l’imprimante ; le service de sauvegarde ne le peut pas. Dans un système réel, la matrice est beaucoup plus grande et la plupart de ses cases sont vides.

Une liste de contrôle d’accès (ACL) stocke une colonne avec son objet. La liste de report.txt nomme alice, bob et backup avec leurs droits respectifs. Une liste de capacités stocke une ligne avec le sujet. Bob détient des jetons pour lire le rapport, lire et modifier les données de paie, et utiliser l’imprimante.

Une capacité désigne à la fois un objet et les opérations autorisées ; son détenteur ne peut ni la falsifier ni en étendre les droits. La copie et la délégation autorisées sont possibles. Le noyau peut détenir le véritable jeton tandis que le code utilisateur détient un indice ; une autre architecture protège le jeton par cryptographie.

Suis un descripteur après l’ouverture

Unix combine les deux approches. open() vérifie les droits de l’appelant par rapport aux permissions du fichier, puis renvoie un descripteur de fichier qui enregistre l’accès accordé. Les lectures et écritures ultérieures vérifient cette référence ouverte. Un processus fils peut en hériter par fork(), ou un processus peut la recevoir par une socket de domaine Unix.

Alice ouvre app.log en écriture. Son propriétaire change le mode en 444. Le descripteur déjà ouvert d’alice permet toujours d’écrire ; une nouvelle tentative d’ouverture du fichier en écriture se heurte au nouveau mode. Mettre à jour l’ACL qui régit les ouvertures futures n’annule pas toutes les capacités déjà délivrées. Les handles Windows suivent le même principe général.

Capsicum de FreeBSD rend cela utile pour le confinement. Après cap_enter(), un processus ne peut pas ouvrir un chemin absolu arbitraire. Il peut agir au moyen des descripteurs existants, recevoir des descripteurs et utiliser openat() sous un descripteur de répertoire qu’il détient. Un processus père peut donc donner à un processus travailleur exactement les fichiers dont il a besoin. Les noyaux fondés sur les capacités tels que seL4 et Fuchsia étendent l’idée aux objets du noyau en général.

Distingue l’autre sens de capacité sous Linux

Les capacités Linux répartissent les privilèges de root en catégories. CAP_NET_BIND_SERVICE permet de se lier aux ports de numéro inférieur ; CAP_DAC_OVERRIDE contourne les vérifications ordinaires d’accès aux fichiers. Ces privilèges ne désignent pas un objet particulier : ils diffèrent donc d’une capacité au sens de la matrice d’accès. Un seul privilège Linux peut autoriser une catégorie d’opérations sur de nombreux objets.

Les permissions Unix associent des droits au propriétaire, au groupe propriétaire et à tous les autres. Pour décider d’un accès, identifie d’abord l’opération et l’objet concerné. Lire le contenu d’un fichier, traverser un répertoire et supprimer un nom exigent des permissions différentes.

Décode et sélectionne les bits

La lecture vaut 4, l’écriture 2 et l’exécution 1. Additionne ces valeurs pour chaque classe : 754 signifie rwxr-xr-- ; 640 signifie rw-r-----. chmod 640 notes.txt définit un mode, tandis que chmod g+w,o-r notes.txt modifie certains bits. Le propriétaire ou root peut modifier le mode ; changer le propriétaire exige les privilèges root, représentés par CAP_CHOWN sous Linux.

Le noyau sélectionne la première classe correspondante : propriétaire si l’UID effectif correspond, sinon groupe si un groupe du processus correspond, sinon autres. Il ne combine pas les classes et n’essaie pas une classe plus généreuse. Alice possède un fichier de mode 077 : ses bits de propriétaire n’accordent aucun droit, elle ne peut donc pas le lire même si le groupe et les autres ont tous les droits. En tant que propriétaire, elle peut toutefois modifier le mode.

Root contourne normalement les vérifications de lecture et d’écriture. Pour exécuter un fichier ordinaire soumis aux vérifications discrétionnaires habituelles de Linux, au moins un bit d’exécution doit être activé. Une politique obligatoire peut imposer d’autres restrictions.

Interprète les bits des répertoires et les bits spéciaux

Pour un répertoire, la lecture permet de répertorier les noms ; l’exécution autorise la traversée et la recherche ; l’écriture associée à l’exécution permet de créer, supprimer et renommer des entrées. Supprimer un nom modifie son répertoire : un fichier de mode 000 peut donc être supprimé par une personne disposant des droits nécessaires sur le répertoire.

Setuid ajoute 4000 en octal au mode d’un exécutable et change l’identité utilisateur effective lors de son exécution. Setgid ajoute 2000 et change de la même façon le groupe ; sur un répertoire, il fait hériter aux nouveaux fichiers le groupe du répertoire. Le bit de restriction de suppression ajoute 1000. Un répertoire tel que /tmp, de mode 1777, n’autorise la suppression ou le renommage que par le propriétaire du fichier, le propriétaire du répertoire ou un processus privilégié, les permissions ordinaires sur le répertoire restant nécessaires.

Retire des bits lors de la création de fichiers

Un umask désactive des bits du mode demandé par un programme. C’est une opération sur les bits, pas une soustraction octale. Avec les demandes habituelles de 666 pour les fichiers et de 777 pour les répertoires :

Un umask ne peut pas ajouter des droits d’exécution absents de la demande pour le fichier.

Lis des listes d’accès plus détaillées

Les ACL POSIX ajoutent des utilisateurs et des groupes nommés. setfacl -m u:bob:r report.txt donne à bob une entrée nominative de lecture ; getfacl l’affiche et ls -l marque l’ACL étendue avec +. Le masque d’ACL limite les utilisateurs nommés, les groupes nommés et le groupe propriétaire : une entrée nominative peut donc afficher plus de droits que ceux qui sont effectifs.

Windows NTFS utilise un descripteur de sécurité avec un SID propriétaire et une DACL composée d’ACE ordonnées qui autorisent ou refusent des droits. L’évaluation s’arrête dès qu’un droit demandé est refusé ou que tous les droits demandés ont été accordés ; les droits non accordés sont refusés. L’ordre recommandé place les entrées explicites avant les entrées héritées, avec les refus avant les autorisations dans chaque groupe. Une autorisation explicite peut donc régler une demande avant qu’un refus hérité soit atteint. Une SACL distincte sélectionne les événements d’accès à auditer.

Les différents modèles de contrôle d’accès répondent à différentes questions de gestion. Qui peut accorder un accès ? Un programme compromis peut-il partager les données d’un utilisateur ? Comment un administrateur peut-il changer les droits de nombreux employés sans modifier chaque fichier ? Un même système d’exploitation peut appliquer plusieurs modèles à une même demande.

Distingue le choix du propriétaire de la politique système

Dans le contrôle d’accès discrétionnaire (DAC), le propriétaire d’un objet décide qui peut l’utiliser. Les modes et les ACL Unix sont des mécanismes courants. Leur faiblesse est qu’un programme malveillant agissant sous l’identité de l’utilisateur peut exercer les droits de celui-ci, notamment copier ailleurs les données qu’il peut lire.

Dans le contrôle d’accès obligatoire (MAC), une politique définie par l’administrateur pour l’ensemble du système limite les accès indépendamment des souhaits du propriétaire. Le noyau applique le MAC en plus du DAC. Les deux vérifications doivent autoriser l’accès : un mode de fichier permissif ne l’emporte donc pas sur un refus obligatoire.

Le modèle de Bell–LaPadula protège la confidentialité à l’aide de niveaux ordonnés et de deux règles : pas de lecture vers le haut et pas d’écriture vers le bas. Un processus Secret peut lire des données Confidentiel et écrire vers une destination Très Secret. Il ne peut pas lire des données Très Secret ni écrire des données Confidentiel. Un programme ne peut pas transférer des informations de Secret vers Confidentiel simplement en les lisant et en les réécrivant. Le modèle de Biba inverse les directions de lecture et d’écriture pour protéger l’intégrité.

Confine un service même lorsqu’il est root

SELinux attribue des étiquettes de type aux fichiers et exécute les processus dans des domaines. Une politique indique quel domaine peut effectuer quelles opérations sur chaque type ; les accès non répertoriés sont refusés. Un serveur web dans httpd_t peut lire les pages étiquetées httpd_sys_content_t tout en étant bloqué pour user_home_t, même si les modes Unix ordinaires autorisent la lecture. ls -Z affiche les étiquettes.

En mode enforcing, SELinux bloque et journalise les violations. En mode permissive, il les journalise sans les bloquer. Root dans un domaine confiné doit toujours respecter une politique appliquée en mode enforcing. L’UID 0 et l’accès sans restriction sont donc deux affirmations différentes.

AppArmor confine les programmes avec des profils fondés sur les chemins de fichiers et les capacités autorisées. Il est couramment utilisé sur Ubuntu et SUSE. SELinux et AppArmor fonctionnent par l’intermédiaire des points d’accroche des modules de sécurité Linux (LSM) lors des décisions de sécurité. Android combine des UID propres aux applications avec SELinux ; les systèmes Apple utilisent aussi des profils de bac à sable pour les applications.

Attribue des rôles professionnels plutôt que des droits individuels

Dans le contrôle d’accès fondé sur les rôles (RBAC), les permissions sont associées aux rôles et les utilisateurs sont affectés à des rôles. Faire passer une personne d’un poste à un autre modifie ses rôles plutôt que de nombreuses permissions indépendantes sur les objets.

Supposons que 50 employés aient chacun besoin de 20 permissions. Une attribution directe nécessite 1 000 liens entre utilisateurs et permissions. Si cinq rôles détiennent chacun 20 permissions et que chaque employé a un rôle, la gestion nécessite 50 liens entre utilisateurs et rôles et 100 liens entre rôles et permissions : 150 au total. L’économie provient des profils de poste partagés, pas de la suppression de permissions nécessaires.

Les groupes Windows utilisés comme rôles et les politiques sudo fondées sur les groupes mettent en œuvre ce principe. Le DAC convient aux fichiers gérés par leur propriétaire, le MAC confine les services selon des règles appliquées de façon centralisée et le RBAC organise les attributions administratives. Un service peut recevoir les droits liés à sa fonction par un rôle, tandis que le DAC et le MAC vérifient tous deux son accès effectif aux fichiers.

Une machine virtuelle donne à un système d’exploitation complet l’apparence de disposer de son propre ordinateur. Ce système d’exploitation est le système invité. L’ordinateur physique est l’hôte, et l’hyperviseur, ou moniteur de machine virtuelle (VMM), attribue aux invités du temps processeur réel, de la mémoire et des périphériques.

Préserve le comportement tout en gardant le contrôle

Le cadre défini par Popek et Goldberg en 1974 identifie trois propriétés. L’équivalence signifie que les programmes se comportent comme sur une machine réelle, à l’exception des temps d’exécution et des ressources disponibles. Le contrôle des ressources signifie que l’hyperviseur garde la maîtrise du matériel. L’efficacité signifie que la plupart des instructions de l’invité s’exécutent directement sur le processeur.

L’hyperviseur ordonnance les processeurs virtuels (vCPU) sur les cœurs physiques. Une commutation de machine sauvegarde l’état d’exécution complet d’une machine virtuelle, y compris les registres privilégiés et les paramètres d’interruption, puis restaure celui d’une autre. Un invité voit son propre état même lorsqu’il partage un cœur physique avec d’autres invités.

KVM transforme le noyau Linux lui-même en hyperviseur et est généralement classé dans le type 1. Un hôte Linux complet reste disponible, ce qui rend la distinction simple entre les deux types moins nette. Pour raisonner sur la protection, identifie le composant qui contrôle réellement la virtualisation du processeur et de la mémoire.

Utilise l’abstraction de la machine

La consolidation des serveurs regroupe des systèmes peu utilisés. Douze serveurs utilisant chacun en moyenne 5 % d’un ordinateur à huit cœurs ont besoin, ensemble, de 60 % d’un tel ordinateur. Cette moyenne laisse penser que la consolidation est possible, mais les pics simultanés, les besoins en mémoire vive et les demandes aux périphériques exigent encore une marge.

Un instantané sauvegarde l’état d’une machine virtuelle pour une restauration ultérieure. Copier une image disque seule ne capture pas l’état d’un processeur en cours d’exécution et de sa mémoire. La migration à chaud transfère une machine virtuelle en cours d’exécution vers un autre hôte, en copiant la mémoire et en basculant l’exécution après une courte pause. Ces opérations sont possibles parce que l’état machine de l’invité est représenté par des données que l’hyperviseur gère.

Les machines virtuelles permettent aussi de tester d’anciens systèmes, de séparer des logiciels incompatibles et d’exécuter différents systèmes d’exploitation sur du matériel compatible. Un invité Windows peut s’exécuter dans une machine virtuelle à côté d’un invité Linux, chacun avec son propre noyau. Les instances de serveur dans le cloud utilisent couramment cette frontière.

Distingue la virtualisation de l’émulation complète

Un émulateur peut interpréter ou traduire un jeu d’instructions pour un autre processeur, comme du code ARM sur x86. La virtualisation matérielle exécute normalement les instructions de l’invité directement sur un processeur compatible et intervient lors d’événements sensibles. Cela explique à la fois sa vitesse et son besoin d’une prise en charge par le processeur.

Des noyaux invités distincts forment une frontière utile : prendre le contrôle d’un noyau invité ne donne pas directement le contrôle du noyau hôte. Cette frontière dépend toutefois du bon fonctionnement du code de l’hyperviseur et du modèle de périphérique. Une évasion de machine virtuelle exploite cette couche, tandis qu’un canal auxiliaire peut divulguer des données par le matériel partagé sans accorder d’accès mémoire ordinaire. Choisir une machine virtuelle réduit les interfaces exposées à un invité non fiable ; cela ne rend pas le matériel partagé infaillible.

Un noyau invité s’attend à contrôler sa machine. L’hyperviseur doit préserver cette apparence sans lui céder l’ordinateur réel. La virtualisation du processeur permet aux instructions ordinaires de l’invité de s’exécuter directement et intercepte les opérations qui doivent modifier l’état de la machine virtuelle.

Intercepte et émule l’état virtuel

Dans le mécanisme classique d’interception et émulation, le noyau invité est déprivé. Sa tentative de charger un registre de table des pages ou d’installer une table des vecteurs de déroutement provoque un déroutement vers l’hyperviseur. Celui-ci met à jour le registre ou la table virtuelle de l’invité et reprend l’exécution. Il ne laisse pas l’invité remplacer les structures de contrôle réelles de l’hyperviseur.

Dans cette architecture, un appel système de l’invité peut nécessiter plusieurs franchissements. L’application invitée provoque un déroutement vers le gestionnaire réel de l’hyperviseur. Celui-ci transfère l’exécution au gestionnaire enregistré du noyau invité avec des privilèges réduits. Lorsque le noyau invité revient, ce retour privilégié provoque un nouveau déroutement ; l’hyperviseur effectue le retour réel vers l’application invitée.

La condition de Popek et Goldberg pour cette technique est que toute instruction sensible soit privilégiée. Sensible signifie qu’elle modifie la configuration de la machine ou se comporte différemment selon les privilèges. Privilégiée signifie qu’elle provoque un déroutement hors du mode le plus privilégié. Les différences silencieuses ne peuvent pas être émulées si l’hyperviseur n’apprend jamais qu’elles se sont produites.

Comprends l’obstacle du x86 classique

L’analyse de Robin et Irvine en 2000 a identifié 17 instructions x86 sensibles non privilégiées. Par exemple, POPF peut restaurer l’indicateur d’activation des interruptions avec des privilèges suffisants, mais le laisse silencieusement inchangé avec des privilèges réduits. Un invité déprivé peut croire qu’il a désactivé les interruptions alors qu’aucun déroutement n’a informé l’hyperviseur qu’il devait mettre à jour son état virtuel des interruptions.

Trois approches résolvent ce problème :

VMware a utilisé la traduction binaire en 1999 ; Xen a utilisé la paravirtualisation en 2003. Intel VT-x est arrivé en 2005 et AMD-V en 2006. Les applications ordinaires de l’invité peuvent toujours s’exécuter directement lorsque le code du noyau nécessite une traduction ou des hyperappels.

Distingue le numéro d’anneau du mode de virtualisation

Avec Intel VT-x, l’hyperviseur s’exécute en mode VMX root et un invité en mode non-root. Le noyau invité peut y utiliser l’anneau 0. L’anneau 0 dans un invité ne donne pas le contrôle de l’hôte physique.

Les événements configurés provoquent une sortie de machine virtuelle, qui sauvegarde l’état du vCPU dans une structure de contrôle telle que la VMCS. L’hyperviseur traite l’événement et reprend l’exécution par une entrée en machine virtuelle. De nombreux appels système peuvent rester entièrement à l’intérieur de l’invité. ARM utilise EL2 pour l’hyperviseur ; RISC-V fournit une extension pour hyperviseur.

Si un invité exécute HLT et que cet événement est configuré pour provoquer une sortie, l’hyperviseur marque son vCPU comme étant en attente et ordonnance un autre travail jusqu’à l’arrivée d’une interruption virtuelle. Le cœur physique n’a pas besoin de rester inactif. Les sorties et les entrées prennent toutefois du temps, généralement de centaines à des milliers de cycles : le regroupement et les interfaces paravirtuelles restent donc utiles.

Une application invitée utilise une adresse virtuelle de l’invité. Son noyau la traduit en adresse physique de l’invité, qui correspond à la représentation de la mémoire vive par l’invité. L’hyperviseur associe ensuite cette adresse à une adresse physique de l’hôte, ou adresse machine. Chaque invité peut croire que sa mémoire vive commence à zéro tout en utilisant des cadres réels différents.

Conserve le déplacement dans la page

Utilise des pages de 4 KiB. L’invité associe la page virtuelle 2 au cadre 7 de l’invité ; l’hyperviseur associe le cadre 7 de l’invité au cadre machine 42. Pour l’adresse 0x2ABC :

1. Décompose-la en page 2 et déplacement 0xABC.
2. Remplace la page 2 par le cadre 7 de l’invité, ce qui donne 0x7ABC.
3. Remplace le cadre 7 de l’invité par le cadre machine 42, soit 0x2A en hexadécimal.
4. Conserve le déplacement, ce qui donne l’adresse machine 0x2AABC, soit 174 780 octets à partir de l’adresse zéro.

Seul le numéro de page change. Traiter l’adresse physique de l’invité comme une adresse réelle en mémoire vive contournerait la décision d’allocation et d’isolation de l’hyperviseur.

Compare la traduction logicielle et matérielle

Les tables des pages fantômes associent directement les pages virtuelles de l’invité aux cadres machine. La MMU réelle utilise ces tables construites par l’hyperviseur. Celui-ci protège en écriture les pages contenant les tables des pages de l’invité et intercepte les modifications et les changements de table de l’invité afin que ses tables fantômes restent cohérentes. Des changements fréquents d’espace d’adressage de l’invité provoquent donc des déroutements supplémentaires.

La pagination imbriquée, Intel EPT ou AMD NPT, confie les deux étapes à la MMU. Le matériel parcourt les tables de l’invité et les tables qui associent les adresses physiques de l’invité aux adresses machine. Les mises à jour des tables des pages de l’invité n’ont plus toutes besoin d’être interceptées par logiciel. Le TLB met en cache la traduction finale combinée.

Un échec de recherche dans le cache peut rester coûteux. Avec quatre niveaux à chaque étape, chacune des quatre entrées de la table de l’invité nécessite quatre accès à la table imbriquée, plus l’accès à l’entrée elle-même : 20 accès. La traduction de l’adresse physique finale des données de l’invité en ajoute quatre, soit 24 accès de traduction avant l’accès aux données. Les pages de grande taille et les caches de parcours des tables des pages réduisent ce travail dans le pire des cas, sans résultat en cache.

Récupère de la mémoire malgré une connaissance limitée de l’invité

La surallocation mémoire promet aux invités plus de mémoire au total que l’hôte n’en possède. Quatre machines virtuelles de 16 GiB totalisent 64 GiB sur un hôte de 48 GiB. Cela ne fonctionne que tant que leurs besoins effectifs tiennent dans la mémoire disponible ; si elles deviennent toutes occupées, il faut récupérer de la mémoire ou utiliser l’espace d’échange.

Un pilote de ballonnement dans un invité alloue des pages à la demande de l’hyperviseur. Le système invité choisit ce qu’il libère, tandis que l’hyperviseur récupère les cadres machine correspondant aux pages du ballon. Cela réduit le déficit d’information : l’invité sait quelles données comptent, tandis que l’hyperviseur voit les allocations sans en connaître tout le sens.

Le partage de pages, comme avec KSM de Linux, fusionne les pages identiques en une copie en lecture seule et les sépare en cas d’écriture. L’échange de pages par l’hyperviseur offre un autre recours, mais peut faire de mauvais choix faute de disposer des connaissances de l’invité. Un périphérique directement affecté à la machine virtuelle a aussi besoin d’une IOMMU pour traduire et limiter ses adresses DMA.

Le partage de pages identiques entre clients a un coût pour la confidentialité : la durée d’une copie sur écriture peut révéler si un autre invité détient les mêmes données. Les fournisseurs de cloud désactivent couramment cette forme de partage entre clients, même si elle économise de la mémoire.

Une machine virtuelle a besoin de stockage, d’un réseau et d’autres périphériques en plus du temps processeur et de la mémoire vive. L’interface de périphérique influe sur la compatibilité, les performances et le code qu’un invité non fiable peut atteindre. Une interface rapide et une interface de confiance restreinte sont des choix de conception liés, mais ne constituent pas la même propriété.

Choisis comment l’invité accède à un périphérique

Un programme auxiliaire tel que QEMU peut émuler une carte réseau Intel e1000. Le pilote ordinaire de l’invité écrit dans des registres connus ; le programme auxiliaire en réalise les effets. Des accès fréquents aux registres peuvent provoquer de nombreuses sorties et opérations logicielles.

Un pilote virtio, lui, échange des requêtes par des files en mémoire partagée. Il peut placer plusieurs opérations dans une file et notifier une seule fois le composant qui les traite. Les périphériques vmxnet3 de VMware et VMBus de Hyper-V suivent des architectures apparentées conçues pour la virtualisation. Un pilote de périphérique paravirtuel ne signifie pas que tout le noyau invité doit utiliser des opérations processeur paravirtuelles.

Avec l’affectation directe de périphérique, l’invité dispose d’un périphérique physique ou d’une fonction virtuelle SR-IOV. L’IOMMU limite le DMA à la mémoire de la machine virtuelle. L’affectation directe réduit les interventions logicielles, mais le transfert de l’état du périphérique vers un autre hôte peut rendre la migration à chaud difficile.

Traite les disques virtuels comme un état géré

Un disque virtuel est généralement un fichier sur l’hôte, tel que qcow2, VMDK ou VHDX, ou un volume de stockage. Les images à copie sur écriture permettent à de nombreux invités de partager une base tout en enregistrant des modifications distinctes. Les instantanés peuvent conserver l’état du disque à faible coût, et un instantané complet d’une machine en cours d’exécution nécessite aussi son état d’exécution et sa mémoire. Le clonage et la migration reposent sur la capacité de l’hyperviseur à gérer ces représentations.

Repère la frontière qu’un attaquant doit franchir

Un noyau invité compromis contrôle déjà sa machine virtuelle, mais atteindre l’hôte exige une évasion de machine virtuelle ou une autre défaillance de frontière. La faille VENOM de 2015 touchait le contrôleur de lecteur de disquettes émulé de QEMU et pouvait permettre au code invité de s’exécuter dans le processus QEMU de l’hôte. Maintenir l’émulation des périphériques dans un processus distinct placé dans un bac à sable limite les pouvoirs exposés par un tel bogue.

Les caches de processeur, les prédicteurs de branchement et les bus mémoire partagés créent aussi des canaux auxiliaires. Spectre et L1TF ont montré que l’isolation ne peut pas être jugée à partir des seules projections de pages. Les mesures d’atténuation comprennent les mises à jour du processeur et du microcode, l’effacement de l’état pertinent entre invités et l’évitement du placement simultané de clients différents sur les fils d’exécution matériels d’un même cœur.

L’informatique confidentielle, notamment AMD SEV-SNP et Intel TDX, protège la mémoire de l’invité contre l’hyperviseur grâce à des clés de chiffrement détenues par le matériel et permet l’attestation de l’environnement lancé. Elle étend la frontière de confiance face à un hôte ou à un opérateur compromis. Elle ne supprime ni tous les canaux auxiliaires ni toutes les possibilités pour un hôte d’interrompre le service. La sécurité des machines virtuelles dépend toujours de l’hyperviseur, des interfaces de périphériques, du matériel et de leur configuration.

Un conteneur Linux est un ensemble de processus utilisant le noyau de l’hôte avec des vues et des privilèges restreints. Il n’a ni noyau distinct ni ordinateur émulé. Les espaces de noms donnent aux processus des instances privées de ressources qui seraient autrement globales.

Associe chaque espace de noms à sa vue

clone() avec des options d’espace de noms crée un processus fils dans les nouveaux espaces de noms sélectionnés. unshare() sépare le contexte des espaces de noms, et setns() rejoint un espace de noms existant par un descripteur tel que celui ouvert depuis /proc/1234/ns/net. La réassociation PID affecte les processus fils créés ensuite sans déplacer l’appelant. Pour les espaces de noms temps, unshare(CLONE_NEWTIME) prépare aussi un espace de noms pour les processus fils créés ensuite ; setns() peut déplacer l’appelant dans un espace de noms temps existant. Les espaces de noms temps sont créés avec unshare().

Ainsi, unshare --pid --fork --mount-proc bash utilise --fork pour créer l’interpréteur dans le nouvel espace de noms PID. Cet interpréteur y est le PID 1, même si son PID sur l’hôte est 48213. Le PID 1 adopte les processus orphelins ; s’il se termine, le noyau met fin aux processus restants de l’espace de noms. Les processus d’un espace de noms ancêtre peuvent voir leurs descendants, tandis que les processus internes ne peuvent pas voir vers l’extérieur dans les espaces de noms PID ancêtres.

Sépare les fichiers et le réseau

Un espace de noms de montage fournit une liste de montages privée. Un moteur d’exécution assemble une arborescence de fichiers et en fait la racine avec pivot_root. Un conteneur peut utiliser les /etc et /usr d’une autre distribution Linux tout en faisant appel au noyau de l’hôte. chroot seul ne change que le point de départ de la résolution des chemins ; ce n’est pas une frontière sûre contre un processus privilégié.

Un nouvel espace de noms réseau possède une interface de bouclage. Un moteur d’exécution peut le connecter au moyen d’une paire d’interfaces veth, avec une extrémité à l’intérieur et l’autre connectée à un pont de l’hôte. Des piles distinctes permettent à deux conteneurs d’écouter tous deux sur le port 80 sans se disputer le port d’un même espace de noms.

Traduis les identités à travers un espace de noms utilisateur

Une ligne de /proc/<pid>/uid_map indique le premier identifiant interne, le premier identifiant externe et la longueur de la plage. La ligne 0 100000 65536 associe les identifiants internes 0–65535 aux identifiants 100000–165535 de l’hôte. L’UID interne 1000 correspond donc à 101000 à l’extérieur. Les identifiants sans correspondance utilisable sont normalement affichés sous l’UID de débordement 65534.

Root dans cet espace de noms possède des capacités sur les ressources qu’il régit, mais pas de pouvoir sur tout l’hôte. Charger un module du noyau ou changer l’horloge système réelle exige toujours des privilèges dans l’espace de noms utilisateur initial. Une correspondance d’UID ne protège pas une socket privilégiée de moteur d’exécution transmise au conteneur.

Une vue privée ne limite pas non plus la consommation. Un processus disposant de ses propres espaces de noms PID et de montage peut toujours consommer du temps processeur et de la mémoire vive. Les cgroups limitent les quantités, tandis que les limites de capacités et seccomp restreignent les opérations.

Un groupe de contrôle, ou cgroup, rassemble des processus pour comptabiliser et contrôler les ressources. Les espaces de noms déterminent leur vue ; les cgroups régissent des quantités telles que le temps processeur, la mémoire et le nombre de tâches. Les processus fils héritent du groupe de leur père, et la hiérarchie empêche un groupe fils d’échapper aux limites d’un ancêtre.

Lis les fichiers de cgroup v2

Cgroup v2 utilise une hiérarchie unifiée, normalement sur /sys/fs/cgroup. Un groupe père active les contrôleurs pour ses fils par cgroup.subtree_control, par exemple +cpu +memory +pids. Des fichiers individuels dans chaque groupe fils contiennent les limites et les compteurs.

Les contrôleurs comprennent cpu, cpuset, memory, io, pids, hugetlb et rdma. Ils régissent le temps processeur, le placement sur les processeurs et les nœuds mémoire, la mémoire ordinaire, les entrées-sorties en mode bloc, le nombre de tâches, les pages de très grande taille et les ressources RDMA. Les événements de performance prenant en compte les cgroups permettent la mesure, et cgroup.freeze suspend l’exécution d’un groupe.

Distingue une limite de processeur d’une part

cpu.max contient un quota et une période en microsecondes. 50000 100000 autorise 50 ms d’exécution sur le processeur par période de 100 ms, soit l’équivalent de la moitié d’un processeur. 200000 100000 autorise l’équivalent du temps de deux processeurs, éventuellement réparti sur plusieurs cœurs. max 100000 signifie qu’aucun quota ne s’applique. Une fois le quota consommé, le groupe attend la période suivante même si un processeur est inactif.

cpu.weight fixe une part relative en cas de concurrence, de 1 à 10 000, avec 100 par défaut. Pour des groupes prêts à s’exécuter, placés de façon équivalente sur quatre processeurs, les poids 100 et 300 répartissent le temps disponible selon le rapport 1:3 : environ un processeur et trois processeurs. Si le groupe de poids supérieur devient inactif, l’autre peut utiliser les quatre, sauf si une autre limite intervient. Un poids n’est ni une réservation ni un plafond strict.

Contiens l’épuisement de la mémoire et des tâches

memory.high provoque une récupération de mémoire et ralentit les tâches au-delà de son seuil. memory.max impose une limite stricte. Le noyau essaie d’abord de récupérer de la mémoire, notamment le cache, et utilise l’espace d’échange disponible. S’il ne peut pas en récupérer assez, le mécanisme OOM du cgroup termine un processus admissible dans le groupe concerné.

Pour une valeur memory.max de 512M, la limite est de 536 870 912 octets, soit 512 MiB. Un processus présentant une fuite peut forcer la récupération de mémoire et finir par provoquer la mise à mort d’un processus par le mécanisme OOM, mais la victime est choisie par le noyau et n’est pas nécessairement ce processus. La frontière du groupe contient l’événement au lieu de laisser choisir un processus sans rapport sur l’hôte.

pids.max compte les processus et les fils d’exécution. Avec une limite de 100, toute création supplémentaire échoue avec EAGAIN, ce qui contient la croissance des tâches d’une bombe fork. Une limite d’entrées-sorties telle que 8:0 rbps=10485760 dans io.max plafonne les lectures du périphérique en mode bloc 8:0 à 10 MiB/s.

Ces fichiers ne masquent pas les processus ni les noms de fichiers de l’hôte. De plus, /proc/meminfo et les outils qui le lisent peuvent indiquer la mémoire vive de l’hôte au lieu de memory.max ; le total affiché ne prouve pas à lui seul qu’un cgroup n’a pas de limite. Les mesures de ressources doivent être lues à la couche qui fait respecter la frontière.

Une frontière de conteneur utile combine des vues, des contrôles de ressources et des pouvoirs restreints. Une arborescence privée ne bloque pas à elle seule les appels système dangereux, et un quota de processeur ne bloque pas l’accès à un fichier exposé de l’hôte. Le noyau de l’hôte applique chacun de ces contrôles.

Réduis les pouvoirs du processus

Un moteur d’exécution combine des espaces de noms, des cgroups et une image de système de fichiers contenant des programmes et des bibliothèques. Il peut renforcer la frontière en :

• Exécutant la charge de travail sans être root ou en associant les identifiants du conteneur à ceux de l’hôte par un espace de noms utilisateur.
• Abandonnant des capacités Linux, en particulier des pouvoirs étendus tels que CAP_SYS_ADMIN et CAP_SYS_MODULE.
• Appliquant seccomp pour restreindre les appels inutiles.
• Appliquant une politique SELinux ou AppArmor.
• Plaçant le système de fichiers racine en lecture seule lorsque c’est possible.
• Définissant no_new_privs pour que l’exécution de programmes setuid ne puisse pas élever les privilèges.

Chaque contrôle couvre une voie différente. Un système de fichiers racine en lecture seule autorise toujours les opérations réseau permises ; un filtre seccomp autorise toujours les appels de sa liste. La conception devrait correspondre aux opérations dont l’application a réellement besoin.

Identifie le risque du noyau partagé

Tous les conteneurs ordinaires partagent le noyau de l’hôte. Un bogue du noyau accessible peut donc compromettre l’hôte et les autres conteneurs. Dans une machine virtuelle, l’exploitation d’un bogue du noyau invité donne le contrôle de cet invité ; atteindre l’hôte exige une défaillance supplémentaire de la frontière de l’hyperviseur ou des périphériques.

Root dans un conteneur est particulièrement sensible. Sans espace de noms utilisateur, il correspond à l’UID 0 pour le noyau de l’hôte, avec les limites imposées par les capacités, les filtres et la politique obligatoire. Le mode privilégié ou l’accès au système de fichiers racine de l’hôte peut supprimer ces contraintes. Une socket de moteur d’exécution appartenant à root est également dangereuse : son client peut demander au moteur d’effectuer des actions privilégiées. Associer root dans le conteneur à un identifiant non privilégié sur l’hôte ne rend pas cette socket sûre et ne supprime pas les vulnérabilités du noyau.

Choisis une frontière pour la charge de travail

Un conteneur Linux a besoin d’un noyau Linux. Les plateformes Windows et macOS fournissent donc souvent une machine virtuelle Linux sous les conteneurs Linux. Les machines virtuelles démarrent un système d’exploitation et allouent de la mémoire pour chaque noyau ; les conteneurs démarrent des processus ordinaires et permettent de regrouper les charges de travail plus densément.

Reconnais les architectures intermédiaires

gVisor traite de nombreux appels système des conteneurs dans un noyau en espace utilisateur, ce qui réduit le contact direct avec le noyau de l’hôte. Kata Containers donne à chaque bac à sable, généralement un pod Kubernetes, une machine virtuelle légère ; les conteneurs de ce bac à sable partagent son noyau invité. Firecracker fournit des micromachines virtuelles avec un modèle de périphériques minimal pour les plateformes qui exécutent des fonctions ou des charges de travail en conteneurs, notamment AWS Lambda.

Les systèmes cloud placent souvent des conteneurs dans des machines virtuelles : une machine virtuelle sépare les clients tandis que les conteneurs organisent les applications d’un même client. Les noyaux invités et le noyau hôte restent distincts : une évasion de conteneur dans une machine virtuelle ne prouve donc pas à elle seule une évasion de l’hyperviseur.