Questions fréquentes

Puis-je utiliser les threads ?

Oui, les threads sont compatibles avec Sandbox2.

Tous les threads doivent être mis en bac à sable

En raison du fonctionnement de Linux, la règle seccomp-bpf n'est appliquée qu'au thread actuel. Cela signifie que la règle n'est pas appliquée aux autres threads existants, mais que les futurs threads l'hériteront :

  • Si vous utilisez Sandbox2 en premier mode, où le bac à sable est activé avant execve(), tous les threads hériteront de la règle et il n'y aura aucun problème. Il s'agit du mode de bac à sable recommandé.
  • Si vous utilisez le deuxième mode où l'exécuteur a set_enable_sandbox_before_exec(false) et où Sandboxee indique à l'exécuteur quand il souhaite être mis en bac à sable avec SandboxMeHere(), assurez-vous que le filtre est appliqué à tous les threads. Sinon, il existe un risque d'échappement du bac à sable : un code malveillant pourrait migrer d'un thread mis en bac à sable vers un thread non mis en bac à sable.

Comment compiler mon Sandboxee ?

En comparaison avec un exécutable lié statiquement, la compilation du sandboxee en un exécutable lié dynamiquement entraînera une augmentation significative des appels système (par exemple, open/openat, mmap, etc.) qui doivent être ajoutés à la liste d'autorisation. Tous ces appels système supplémentaires sont nécessaires en raison de l'invocation de l'éditeur de liens dynamiques au moment de l'exécution pour charger les bibliothèques partagées.

Cependant, en ce qui concerne les sandboxees liés statiquement, bien que moins d'appels système doivent être ajoutés à la liste d'autorisation, il existe également des implications en termes de sécurité. L'entropie du tas ASLR est réduite (de 30 bits à 8 bits), ce qui facilite les exploits.

Ce dilemme peut être réduit à la question suivante :

  • Dynamique : bonne ASLR du tas, exécution initiale du code potentiellement plus difficile à obtenir, mais au prix d'une règle de bac à sable moins efficace, potentiellement plus facile à contourner.
  • Statique : mauvaise ASLR du tas, exécution initiale du code potentiellement plus facile, mais politique de bac à sable plus efficace, potentiellement plus difficile à contourner.

Historiquement, les binaires liés statiquement n'étaient pas compatibles avec le code indépendant de la position (pie). De plus, Bazel ajoutait pie par défaut. Pour pouvoir définir un filtre syscall strict, vous deviez remplacer la valeur par défaut de Bazel.

Les compilateurs se sont améliorés au fil des ans et sont désormais compatibles avec l'option static-pie. Avec cette option, un compilateur est chargé de générer du code indépendant de la position, mais par rapport à pie, cela inclut désormais également toutes les bibliothèques liées statiquement. Du point de vue de la sécurité, static-pie réduit toujours l'entropie ASLR (de 30 bits à 14 bits), mais cela représente une amélioration par rapport à la situation précédente sans pie.

Comme Bazel ajoute pie par défaut et que le statique n'est pas compatible avec lui, envisagez d'utiliser l'indicateur d'options de l'éditeur de liens pour transmettre l'indicateur d'éditeur de liens -static-pie à la règle cc_binary et remplacer la valeur par défaut :

  linkstatic = 1,
  linkopts=["-static-pie"],

Pour obtenir un exemple de ces options, consultez l'exemple static BUILD : static_bin.cc est associé de manière statique à static-pie, ce qui permet d'avoir une règle syscall très stricte. Cela fonctionne également bien pour le sandboxing des binaires tiers.

Puis-je mettre en bac à sable les binaires x86 32 bits ?

Sandbox2 ne peut mettre en bac à sable que la même architecture que celle avec laquelle il a été compilé.

De plus, la compatibilité avec x86 32 bits a été supprimée de Sandbox2. Si vous essayez d'utiliser un exécutable x86 64 bits pour mettre en bac à sable un binaire x86 32 bits, ou un binaire x86 64 bits effectuant des appels système 32 bits (via int 0x80), les deux généreront une violation du bac à sable qui peut être identifiée par le libellé d'architecture [X86-32].

Ce comportement s'explique par le fait que les numéros de syscall diffèrent entre les architectures. Étant donné que la règle syscall est écrite dans l'architecture de l'exécuteur, il serait dangereux d'autoriser une architecture différente pour Sandboxee. En effet, cela pourrait conduire à autoriser un appel système apparemment inoffensif qui, en fait, signifie qu'un autre appel système plus dangereux pourrait ouvrir le bac à sable à une évasion.

Le nombre de bacs à sable qu'un processus d'exécution peut demander est-il limité ?

Pour chaque instance Sandboxee (nouveau processus généré à partir du forkserver), un nouveau thread est créé. C'est là que réside la limite.

Un administrateur peut-il demander la création de plusieurs bacs à sable ?

Non. Il existe une relation un-à-un : une instance Executor stocke le PID de Sandboxee, gère l'instance Comms vers l'instance Sandbox, etc.

Pourquoi le message "Function not implemented" (Fonction non implémentée) s'affiche-t-il dans forkserver.cc ?

Sandbox2 n'est compatible qu'avec les noyaux relativement récents. Notre seuil actuel est le noyau 3.19, mais il est possible qu'il change à l'avenir. En effet, nous utilisons des fonctionnalités de noyau relativement nouvelles, y compris les espaces de noms utilisateur et seccomp avec l'indicateur TSYNC.

Si vous exécutez sur prod, cela ne devrait pas poser de problème, car la quasi-totalité du parc exécute un noyau suffisamment récent. Si vous rencontrez des problèmes, veuillez nous contacter.

Si vous utilisez Debian ou Ubuntu, il vous suffit d'exécuter la commande suivante pour mettre à jour votre noyau :

sudo apt-get install linux-image-<RECENT_VERSION>