Exemples

Présentation

Nous avons préparé quelques exemples pour vous montrer comment utiliser le bac à sable2 dans différents scénarios et comment rédiger des règles.

Vous les trouverez dans //sandboxed_api/sandbox2/examples. Vous trouverez des explications détaillées ci-dessous.

CRC4

L'exemple CRC4 illustre un calcul délibérément erroné d'une somme de contrôle CRC4, qui montre comment créer un autre programme dans un bac à sable et comment communiquer avec lui.

  • crc4bin.cc: programme de bac à sable (ou Sandboxee)
  • crc4sandbox.cc: programme de bac à sable qui l'exécutera (c'est-à-dire l'exécuteur).

Fonctionnement :

  1. L'exécuteur démarre le Sandboxee à partir de son chemin d'accès au fichier à l'aide de ::sandbox2::GetDataDependencyFilePath().
  2. L'exécuteur envoie une entrée au bac à sableee via le canal de communication Comms à l'aide de SendBytes().
  3. Sandboxee calcule le CRC4 et renvoie ses réponses à l'exécuteur via le canal de communication Comms qui le reçoit avec RecvUint32().

Si le programme effectue un appel système autre que la communication (read() et write()), il est arrêté pour non-respect des règles.

static

L'exemple statique montre comment mettre en bac à sable un binaire associé de manière statique, tel qu'un binaire tiers dont vous ne disposez pas de la source, ce qui signifie qu'il n'est pas au courant qu'il s'exécutera en bac à sable.

  • static_bin.cc: Sandboxee est un binaire C statique qui convertit le texte ASCII d'une entrée standard en majuscules.
  • static_sandbox.cc: exécuteur avec sa règle, ses limites et l'utilisation d'un descripteur de fichier pour l'entrée Sandboxee.

Fonctionnement :

  1. L'exécuteur démarre le Sandboxee à partir de son chemin d'accès au fichier à l'aide de GetDataDependencyFilepath, tout comme pour CRC4.
  2. Elle définit les limites, ouvre un descripteur de fichier sur /proc/version et le marque pour qu'il soit mappé dans le Sandboxee avec MapFd.
  3. La règle permet à certains appels système (open) de renvoyer une erreur (ENOENT) au lieu d'être supprimés pour non-respect des règles. Cela peut être utile lors de l'exécution en bac à sable d'un programme tiers dans lequel nous ne pouvons pas modifier les appels système effectués, afin de pouvoir les faire échouer normalement.

outil

Cet exemple permet à la fois de développer vos propres règles et de tester les API Sandbox2, ainsi qu'une démonstration de ses fonctionnalités.

  • sandbox2tool.cc: l'exécuteur montrant :
    • comment exécuter un autre binaire en bac à sable,
    • comment configurer les vérifications du système de fichiers ; et
    • comment l'exécuteur peut exécuter le Sandboxee de manière asynchrone pour lire ses résultats progressivement.

Essayez par vous-même:

Bazel

bazel run //sandboxed_api/sandbox2/examples/tool:sandbox2tool -- \
--sandbox2tool_resolve_and_add_libraries \
--sandbox2tool_additional_bind_mounts /etc \
/bin/cat /etc/hostname

CMake + Ninja

cd build-dir
ninja sandbox2_sandbox2tool && \
./sandbox2_sandbox2tool \
--sandbox2tool_resolve_and_add_libraries \
--sandbox2tool_additional_bind_mounts /etc \
/bin/cat /etc/hostname

Google3 (Blaze)

blaze run //third_party/sandboxed_api/sandbox2/examples/tool:sandbox2tool -- \
 --sandbox2tool_resolve_and_add_libraries \
 --sandbox2tool_additional_bind_mounts /etc \
 /bin/cat /etc/hostname

Indicateurs:

  • --sandbox2tool_resolve_and_add_libraries pour résoudre et installer les bibliothèques requises pour le bac à sable
  • --sandbox2tool_additional_bind_mounts <PATHS> pour mettre des répertoires supplémentaires à la disposition du bac à sable
  • --sandbox2tool_keep_env pour conserver les variables d'environnement actuelles
  • --sandbox2tool_redirect_fd1 pour recevoir le STDOUT_FILENO (1) Sandboxee et le générer en local
  • --sandbox2tool_cpu_timeout pour définir le délai avant expiration du processeur en secondes
  • --sandbox2tool_walltime_timeout pour définir le délai d'inactivité en secondes
  • --sandbox2tool_file_size_creation_limit pour définir la taille maximale des fichiers créés
  • --sandbox2tool_cwd pour définir le répertoire de travail actuel du bac à sable

custom_fork

L'exemple custom_fork montre comment créer un bac à sable qui initialise le binaire, puis attend les requêtes fork() provenant de l'exécuteur parent.

Ce mode offre des performances potentiellement plus élevées par rapport à d'autres types de bac à sable. Dans ce cas, la création d'instances de bacs à sable ne nécessite pas l'exécution de nouveaux binaires, il suffit de dupliquer les binaires existants.

  • custom_fork_bin.cc: serveur fork personnalisé qui reçoit des requêtes à fork() (via Client::WaitAndFork) pour générer de nouveaux bacs à sable.
  • custom_fork_sandbox.cc: l'exécuteur qui démarre un serveur fork personnalisé. Il envoie ensuite des requêtes (via de nouveaux exécuteurs) pour générer (via fork()) de nouveaux bacs à sable.

réseau

L'espace de noms réseau, qui est activé par défaut, empêche le processus en bac à sable de se connecter au monde extérieur. Cet exemple montre comment résoudre ce problème.

Une connexion est initialisée dans l'exécuteur et le socket obtenu est transmis via ::sandbox2::Comms::SendFD(). Le Sandboxee reçoit le socket en utilisant ::sandbox2::Comms::RecvFD(), puis il peut l'utiliser pour échanger les données comme d'habitude.

network_proxy

Cet exemple présente une autre façon de gérer un espace de noms réseau. En interne, l'API fonctionne exactement de la même manière que dans l'exemple ci-dessus, mais elle est présentée comme une API plus pratique.

Le bac à sable peut établir une connexion réseau de deux manières différentes:

  • automatique : installation d'un gestionnaire automatique, puis émission d'appels de connexion réguliers.
  • manual : en obtenant un NetworkProxyClient et en utilisant directement NetworkProxyClient::Connect.

Cet exemple présente les deux méthodes. Le mode automatique est utilisé lorsque l'indicateur connect_with_handler est défini. Sinon, le mode manuel est utilisé.