La conception de Sandbox2 repose sur des technologies bien connues et établies, un framework de règles et deux processus : l'exécuteur de bac à sable et le bac à sable.
Technologies impliquées
Les sections suivantes couvrent les technologies qui constituent la couche de base de Sandbox2.
Espaces de noms Linux
Les espaces de noms Linux visent à fournir une virtualisation au niveau du système d'exploitation. Bien que plusieurs espaces utilisateur s'exécutent apparemment indépendamment les uns des autres, ils partagent une seule instance de noyau. Sandbox2 utilise les types d'espaces de noms suivants :
- IPC
- Réseau (sauf s'il est explicitement désactivé en appelant
PolicyBuilder::AllowUnrestrictedNetworking()) - Montage (à l'aide d'une vue personnalisée de l'arborescence du système de fichiers)
- PID
- Utilisateur
- UTS
Pour en savoir plus sur les espaces de noms Linux, consultez Wikipédia ou la page de manuel associée.
IPC
Sandbox2 permet d'échanger des données arbitraires entre l'exécuteur de bac à sable et le bac à sable non approuvé. Il prend en charge les messages de type longueur-valeur (TLV), la transmission de descripteurs de fichiers et l'échange d'identifiants via des jetons et des handles.
Seccomp-BPF
Sandbox2 relies on seccomp-bpf, which is an extension to Secure Computing Mode (seccomp) that allows using Berkeley Packet Filter (BPF) rules to filter syscalls.
seccomp est une fonctionnalité du noyau Linux qui limite les appels système d'un processus pour n'autoriser que exit, sigreturn, read et write. Si un processus tente d'exécuter un autre appel système, il est arrêté. L'extension seccomp-bpf offre plus de flexibilité que seccomp. Au lieu d'autoriser un ensemble fixe d'appels système, seccomp-bpf exécute un programme BPF sur les données d'appel système et, en fonction de la valeur de retour du programme, il peut exécuter l'appel système, l'ignorer et renvoyer une valeur factice, arrêter le processus, générer un signal ou notifier le traceur.
Ptrace
L'appel système ptrace (trace de processus) fournit une fonctionnalité qui permet au processus de traceur d'observer et de contrôler l'exécution du processus de trace. Une fois le traceur associé, il contrôle totalement le processus de trace. Pour en savoir plus sur ptrace sur Wikipédia ou sur la page de manuel associée.
Règle de bac à sable
La règle de bac à sable est la partie la plus importante d'un bac à sable, car elle spécifie les actions que le bac à sable peut et ne peut pas exécuter. Une règle de bac à sable comporte deux parties :
- Règle d'appel système
- Configuration de l'espace de noms
Règle d'appel système par défaut
La règle par défaut bloque les appels système qui sont toujours dangereux et prévaut sur la règle étendue fournie par l'utilisateur.
Règle d'appel système étendue
La règle d'appel système étendue peut être créée à l'aide de notre
PolicyBuilder. Cette classe définit un certain nombre de règles pratiques (par exemple, AllowStaticStartup, AllowDynamicStartup, AllowOpen) qui peuvent être utilisées pour améliorer la lisibilité de votre règle.
Dans la plupart des cas, vous devez commencer par
DefaultPolicyBuilder
(sapi::Sandbox2Config::DefaultPolicyBuilder()), qui renvoie un
PolicyBuilder préconfiguré avec une règle de base pour les bibliothread monothread classiques et peut être personnalisé davantage avec des règles supplémentaires
(telles que .AllowDynamicStartup() et .AddLibrariesForBinary() lors de la mise en bac à sable
d'un binaire). Dans l'API en bac à sable (SAPI), DefaultPolicyBuilder() est utilisé par sapi::SandboxConfig::DefaultConfig() avec sapi::SandboxConfig::DefaultFlags(), sapi::SandboxConfig::DefaultEnvironmentVariables() et sapi::Sandbox2Config::DefaultLimits(). La construction directe d'un PolicyBuilder ne doit être utilisée que lorsque DefaultPolicyBuilder() ne peut pas être utilisé ou lorsqu'une configuration précise est requise.
Si vous souhaitez limiter davantage les appels système ou exiger des règles plus complexes, vous pouvez
spécifier des macros BPF brutes avec AddPolicyOnSyscall et AddPolicyOnSyscalls. L'
exemple crc4 utilise ce
mécanisme pour limiter les arguments des appels système read, write et close.
En général, plus la règle de bac à sable est stricte, mieux c'est, car l'exploitation de toute vulnérabilité présente dans le code sera limitée par la règle. Si vous pouvez spécifier exactement les appels système et les arguments requis pour le fonctionnement normal du programme, tout pirate exploitant une vulnérabilité d'exécution de code est également limité aux mêmes limites.
Une règle de bac à sable très stricte peut refuser tous les appels système, à l'exception des lectures et des écritures sur les descripteurs de fichiers d'entrée et de sortie standards. Dans ce bac à sable, un programme peut prendre des entrées, les traiter et renvoyer la sortie. Toutefois, si le processus tente d'effectuer un autre appel système, il est arrêté en raison d'une violation de la règle. Par conséquent, si le processus est compromis (exécution de code par un utilisateur malveillant), il ne peut rien faire de plus néfaste que de produire une sortie incorrecte (que l'exécuteur et d'autres doivent toujours gérer correctement).
Configuration de l'espace de noms
L'objet PolicyBuilder est également utilisé pour configurer la vue individuelle du système de fichiers d'un bac à sable. Des fichiers uniques (AddFile / AddFileAt), des répertoires entiers
(AddDirectory / AddDirectoryAt), ainsi que du stockage temporaire (AddTmpfs)
peuvent être mappés dans l'environnement du bac à sable. En outre, AddLibrariesForBinary peut être utilisé pour mapper automatiquement toutes les bibliothèques nécessaires à l'exécutable lié dynamiquement spécifié.
Indicateurs de ligne de commande
Toute règle Sandbox2 peut être désactivée en spécifiant l'un des indicateurs de ligne de commande suivants. Ces indicateurs sont destinés à des fins de test (par exemple, lors du réglage de la règle d'appel système étendue).
--sandbox2_danger_danger_permit_all--sandbox2_danger_danger_permit_all_and_log
Exécuteur de bac à sable
L'exécuteur de bac à sable est un processus qui n'est pas lui-même mis en bac à sable. Il s'agit du processus de traceur ptrace qui s'associe au bac à sable (processus de trace ptrace). L'exécuteur de bac à sable configure et exécute également une instance de moniteur qui suit le bac à sable et fournit des informations sur l'état.
Sandbox2 autorise trois modes d'exécution : autonome, Sandbox2 Forkserver et Custom Forkserver. Si vous utilisez un forkserver, le bac à sable est créé en tant que processus enfant de l'exécuteur de bac à sable. Ces modes sont expliqués en détail ici.
Bac à sable
Le bac à sable est le processus qui s'exécute dans l'environnement restreint et mis en bac à sable défini par la règle de bac à sable. L'exécuteur de bac à sable envoie la règle au bac à sable via IPC. Le bac à sable applique ensuite la règle. Toute violation de la règle entraîne l'arrêt du processus, sauf configuration contraire (voir Règle de bac à sable).