Le sandboxing est-il la même chose que la virtualisation ?

Ils se chevauchent mais ne sont pas identiques. La virtualisation exécute des systèmes d'exploitation entiers dans un émulateur ; l'isolation se situe au niveau de la virtualisation matérielle. Le sandboxing exécute généralement des processus au sein du même système d'exploitation avec des restrictions appliquées par le noyau. La virtualisation est plus lourde mais offre une isolation plus forte ; les conceptions modernes combinent souvent les deux (VM Firecracker pour le sans serveur, gVisor pour les conteneurs).

Le sandboxing ralentit-il les choses ?

Frais généraux modestes : généralement un pourcentage à un chiffre pour le filtrage des appels système, légèrement plus pour l'isolation des processus. Le coût des performances a été activement réduit grâce à la prise en charge matérielle (Intel CET, ARM PAC), de sorte que les bacs à sable modernes sont essentiellement gratuits pour la plupart des charges de travail.

Un VPN peut-il échapper à son bac à sable ?

Les logiciels clients VPN nécessitent généralement plus de privilèges que les applications en bac à sable : ils configurent le routage et les interfaces réseau. Sur macOS et iOS, ils utilisent des API spécifiques (framework NetworkExtension) pour le faire en toute sécurité. Le client VPN lui-même est privilégié ; les données qui y circulent sont opaques pour les autres applications.

L'exécution de code dans un conteneur Docker est-elle la même chose que le sandboxing ?

Les conteneurs Docker utilisent les espaces de noms Linux et seccomp pour l'isolation, qui est une forme de sandboxing. L'isolation est plus faible que les sandbox basés sur la virtualisation (les conteneurs partagent le noyau hôte) et plus faible que les sandbox de l'espace utilisateur qui interdisent la plupart des appels système (les conteneurs en autorisent plusieurs). Pour les charges de travail non fiables, des projets comme gVisor ou Kata Containers enveloppent une isolation plus forte autour de Docker UX.

Pourquoi Chrome utilise-t-il autant de mémoire ?

Isolement du site. Chaque origine s'exécute dans son propre processus : 50 onglets de sites différents signifient 50 processus, chacun avec sa propre surcharge de mémoire. Le coût est la RAM ; l'avantage est que l'exploit d'un onglet ne peut pas lire les données d'un autre onglet (mots de passe, sessions). Modern Chrome consacre davantage d'efforts à l'optimisation du partage de mémoire afin de réduire l'impact, mais l'architecture échange intrinsèquement de la mémoire contre de la sécurité.

Le sandboxing expliqué : comment les navigateurs et les systèmes d'exploitation contiennent du code non fiable

Le sandboxing est le modèle de sécurité qui permet à votre navigateur d'exécuter JavaScript à partir de n'importe quel site, à votre téléphone d'exécuter des applications de n'importe quel développeur et à votre ordinateur portable d'ouvrir les pièces jointes des e-mails, le tout sans que ces programmes puissent lire le fichier de votre compte bancaire. C'est la couche technologique qui a transformé un code non fiable d'une vulnérabilité en une fonctionnalité.

Le corps complet de l’article est fourni en anglais ci-dessous.

Sandboxing consiste à exécuter du code dans un environnement restreint qui l'empêche d'accéder aux ressources en dehors de ses limites. Le bac à sable limite les fichiers qu'il peut lire, les connexions réseau qu'il peut établir, les autres processus avec lesquels il peut communiquer et les appels système qu'il peut appeler. Si le code s'avère malveillant ou bogué, les dégâts sont contenus.

Pourquoi le sandboxing est important

L'informatique moderne dépend de l'exécution de codes auxquels nous ne faisons pas entièrement confiance :

JavaScript depuis n'importe quel site Web visité par votre navigateur
Applications mobiles des magasins d'applications (contrôlées mais non formellement vérifiées)
Navigateur extensions, plugins IDE, dépendances dans votre code
Macoros dans les documents, scripts joints aux e-mails
Charges de travail de conteneurs dans l'infrastructure cloud

Sans sandboxing, chacun d'entre eux serait une attaque de vol d'informations d'identification en attente de se produire. Le sandboxing est ce qui permet au modèle de fonctionner.

Comment les sandbox sont construits

Les techniques de mise en œuvre, en couches :

Isolement des processus. Chaque onglet d'un navigateur moderne est un processus de système d'exploitation distinct. Le noyau du navigateur arbitre ce que le processus est autorisé à faire.
seccomp-bpf sous Linux — filtre appliqué par le noyau sur les appels système qu'un processus peut effectuer. Le bac à sable déclare les appels système dont il a besoin (lecture, écriture, mmap, etc.) et le noyau rejette tout le reste.
Espaces de noms et capacités sous Linux — vues isolées du système de fichiers, des processus, du réseau, etc. Les conteneurs sont construits à partir de ces primitives.
App Sandbox sur macOS/iOS — droits déclaratifs décrivant les fonctionnalités dont une application a besoin (accès à la caméra, réseau, chemins spécifiques). Les applications sans droits ne peuvent pas accéder à ces fonctionnalités.
AppContainer / Windows Sandbox — Le modèle d'isolation équivalent de Microsoft.
Isolement de site dans Chrome et Firefox — processus distincts par origine, empêchant le JavaScript d'un site de lire la mémoire d'un autre site même si un exploit au niveau du noyau est trouvé.

Les bacs à sable du navigateur en détail

Le navigateur est le bac à sable le plus public et le plus attaqué en informatique. Le noyau du navigateur s'exécute comme un processus approuvé. Chaque processus de rendu (un ou plusieurs par onglet) s'exécute comme un processus non fiable avec des capacités minimales. Le moteur de rendu peut :

Allouer de la mémoire
Communiquer avec le noyau du navigateur via IPC pour des opérations très spécifiques
Render vers un tampon graphique
Exécuter JavaScript et WebAssembly

It ne peut pas :

Ouvrir des fichiers en dehors de son répertoire sandbox
Parler à des destinations réseau arbitraires (le noyau du navigateur établit ces connexions)
Créer d'autres processus
Lire la mémoire d'autres processus

Les fournisseurs de navigateurs paient des dizaines de millions en bug bounties spécifiquement pour vulnérabilités d'évasion sandbox. La prime la plus lucrative sur Chrome (plus de 200 000 $) concerne une chaîne complète qui échappe au bac à sable.

Boxing pour applications mobiles

iOS et Android poussent le bac à sable à son extrême logique : chaque application s'exécute dans son propre UID, voit sa propre vue de système de fichiers et ne peut communiquer avec d'autres applications que via des canaux IPC étroits médiés par le système d'exploitation (Intents sur Android, URL). schémas et AppExtensions sur iOS). Le système d'exploitation demande à l'utilisateur des autorisations de type capacité (caméra, microphone, contacts) au moment de l'exécution. Résultat : les logiciels malveillants sur un téléphone sont beaucoup plus étroitement contenus que sur un ordinateur de bureau.

WebAssembly et le nouveau sandbox

WebAssembly ont été conçus dès le départ avec le sandboxing comme propriété de première classe. Un module WASM n'a pas d'appel système propre ; tout doit être fourni par l'environnement hôte (WASI pour les API de type appel système, API Web dans les navigateurs). Cela fait de WASM un candidat idéal pour exécuter des plugins non fiables dans des applications fiables – un cas d’utilisation qui nécessitait auparavant une isolation lourde des processus. Des outils comme wasmtime et wasmer utilisent ce modèle.

Lorsque les bacs à sable échouent

Les vulnérabilités d'échappement des bacs à sable sont réelles et prisées. Les modes de pannes récurrentes :

Bugs dans la surface du noyau. Même les processus restreints à seccomp peuvent parfois exploiter des bogues du noyau accessibles via des appels système autorisés.
IPC bugs. Les interfaces que le bac à sable utilise pour communiquer avec le processus du courtier sont elles-mêmes une surface d'attaque.
Canaux latéraux. Spectre et Meltdown a montré que les optimisations du processeur pouvaient faire fuir des données au-delà des limites des processus. Les bacs à sable modernes atténuent ce problème, mais le problème sous-jacent reste un problème au niveau matériel.
Erreurs de profil sandbox. Les opérateurs desserrent parfois les profils sandbox pour faire fonctionner le logiciel, ouvrant accidentellement des trous. La défense en profondeur combine le sandboxing avec d'autres mesures (langages sécurisés pour la mémoire, désinfectants, réduction de la surface d'attaque).
Ce que le sandboxing signifie pour vous
Pour les utilisateurs finaux, le sandboxing est généralement invisible. L'implication pratique : gardez les navigateurs et les systèmes d'exploitation à jour, car les échappements de sandbox sont les correctifs de sécurité les plus prioritaires. Évitez de désactiver les fonctionnalités du bac à sable (certains utilisateurs de Linux désactivent les profils seccomp, certains utilisateurs expérimentés désactivent les indicateurs du bac à sable de Chrome) à moins que vous n'en compreniez les conséquences. Les navigateurs sont livrés renforcés par défaut ; la valeur par défaut est correcte pour presque tous les utilisateurs.

Questions fréquemment posées

Le sandboxing est-il la même chose que la virtualisation ?: Ils se chevauchent mais ne sont pas identiques. La virtualisation exécute des systèmes d'exploitation entiers dans un émulateur ; l'isolation se situe au niveau de la virtualisation matérielle. Le sandboxing exécute généralement des processus au sein du même système d'exploitation avec des restrictions appliquées par le noyau. La virtualisation est plus lourde mais offre une isolation plus forte ; les conceptions modernes combinent souvent les deux (VM Firecracker pour le sans serveur, gVisor pour les conteneurs).
Le sandboxing ralentit-il les choses ?: Frais généraux modestes : généralement un pourcentage à un chiffre pour le filtrage des appels système, légèrement plus pour l'isolation des processus. Le coût des performances a été activement réduit grâce à la prise en charge matérielle (Intel CET, ARM PAC), de sorte que les bacs à sable modernes sont essentiellement gratuits pour la plupart des charges de travail.
Un VPN peut-il échapper à son bac à sable ?: Les logiciels clients VPN nécessitent généralement plus de privilèges que les applications en bac à sable : ils configurent le routage et les interfaces réseau. Sur macOS et iOS, ils utilisent des API spécifiques (framework NetworkExtension) pour le faire en toute sécurité. Le client VPN lui-même est privilégié ; les données qui y circulent sont opaques pour les autres applications.
L'exécution de code dans un conteneur Docker est-elle la même chose que le sandboxing ?: Les conteneurs Docker utilisent les espaces de noms Linux et seccomp pour l'isolation, qui est une forme de sandboxing. L'isolation est plus faible que les sandbox basés sur la virtualisation (les conteneurs partagent le noyau hôte) et plus faible que les sandbox de l'espace utilisateur qui interdisent la plupart des appels système (les conteneurs en autorisent plusieurs). Pour les charges de travail non fiables, des projets comme gVisor ou Kata Containers enveloppent une isolation plus forte autour de Docker UX.
Pourquoi Chrome utilise-t-il autant de mémoire ?: Isolement du site. Chaque origine s'exécute dans son propre processus : 50 onglets de sites différents signifient 50 processus, chacun avec sa propre surcharge de mémoire. Le coût est la RAM ; l'avantage est que l'exploit d'un onglet ne peut pas lire les données d'un autre onglet (mots de passe, sessions). Modern Chrome consacre davantage d'efforts à l'optimisation du partage de mémoire afin de réduire l'impact, mais l'architecture échange intrinsèquement de la mémoire contre de la sécurité.