Isoler ses outils avec Greywall

Posté le - Astuces pour développeurs Par Grafikart

Les actualités récentes nous ont montré qu'en tant que développeur, on doit être attentif lorsqu'on exécute des commandes, que ce soit avec les agents IA ou avec les outils que l'on utilise au quotidien. Les dépendances que l'on importe dans nos projets peuvent aussi devenir de bons vecteurs d'attaque. Greywall apporte une couche de protection en offrant la possibilité d'exécuter les commandes dans un bac à sable afin de contrôler ce à quoi les outils ont accès. L'outil repose sur deux composants : Greywall, qui met en place la sandbox sur Linux et macOS, et Greyproxy, qui intercepte les requêtes réseau pour les autoriser ou les bloquer.

Installation et vérification

Greywall peut être installé avec la commande proposée dans sa documentation ou via Go (vous pouvez suivre les instructions du README sur GitHub). Une fois l'outil installé, on peut vérifier que le système est correctement configuré avec :

greywall check

Si certaines dépendances ou services ne sont pas prêts, on peut lancer :

greywall setup

Lancer une commande dans la sandbox

Pour exécuter une commande avec Greywall, on utilise greywall, puis --, puis la commande à lancer :

greywall -- php script.php # Ou avec le drapeau -c greywall -c "php script.php"

Si le code essaie d'accéder à un dossier non autorisé, il sera automatiquement bloqué. S'il essaie de se connecter à un domaine, il sera aussi bloqué par le proxy qui vous demandera de confirmer l'accès à l'adresse demandée.

Greyproxy expose un dashboard sur le port 43080 où l'on peut voir les requêtes en attente, mais aussi des statistiques sur les différents accès réseau effectués par les commandes gérées par Greyproxy. Attention cependant à la gestion du TLS : par défaut, Greyproxy utilise un certificat local pour intercepter les requêtes HTTPS et déchiffre le trafic avant de le renvoyer à la destination finale. Dans certains cas, cela peut poser des problèmes et je vous conseille de désactiver cette option dans les paramètres du dashboard (cela supprime certaines fonctionnalités qui ne sont pas essentielles à mon sens).

Contrôler l'accès au système de fichiers

Par défaut, une commande exécutée dans Greywall n'a accès qu'au dossier courant en écriture et en lecture. Si le script tente d'écrire dans un autre dossier, l'opération est bloquée. Pour plus de contrôle, Greywall permet de définir des règles plus fines avec des profils. On peut préciser :

Utiliser les profils

Greywall est pensé pour les agents IA et propose des profils préintégrés pour certains outils connus. Par exemple, lorsqu'on lance Codex pour la première fois avec Greywall :

greywall -- codex

Il va proposer de créer un profil déjà rempli avec les dossiers connus et utilisés par Codex. Un profil est un fichier JSON qui décrit les permissions du système de fichiers et du réseau. Si une commande ne fonctionne pas parce qu'elle a besoin d'un dossier supplémentaire, on peut modifier ce profil et ajouter l'accès nécessaire.

{ "filesystem": { "allowWrite": [".", "/tmp"], "allowRead": [".", "/tmp", "~/.bun"], "denyRead": ["/etc/passwd"], "denyWrite": [".git"] } }

Petite précision : si votre commande démarre un serveur local, vous devrez écouter sur 127.0.0.1 et exposer le port avec le drapeau -p.

greywall -p 8000 -- php -S 127.0.0.1:8000

Le mode learning

Greywall propose un mode d'apprentissage avec le drapeau --learning :

greywall --learning -- php script.php

Dans ce mode, les permissions ne sont pas contraintes. La commande a accès au système comme si elle était lancée normalement, mais Greywall observe ce qui se passe et génère un profil JSON correspondant aux accès utilisés. Cela peut être utile si on a pleinement confiance dans une commande et que l'on veut créer rapidement une base de profil. Ensuite, on peut relancer la commande sans --learning.

Personnellement, il peut être préférable de partir d'un profil vide et d'ajouter manuellement les autorisations nécessaires. Cela évite d'accorder trop de permissions dès le départ.

Pourquoi ne pas utiliser uniquement des conteneurs ?

Les conteneurs protègent bien le système de fichiers, mais ils ajoutent aussi de la complexité. Il faut souvent recréer un environnement avec les bons outils, gérer les volumes, et faire attention aux permissions, notamment parce que beaucoup de choses sont lancées en root au sein du conteneur.

L'autre différence importante concerne le réseau. Un conteneur a souvent accès au réseau par défaut et un script dans un conteneur peut exfiltrer des données en contactant un domaine particulier. La seule option est de bloquer l'accès au réseau, mais cela va poser des problèmes lors de l'utilisation de services tiers.

Bilan

Greywall est encore un projet jeune, avec une documentation assez sommaire, mais l'idée est intéressante. À l'heure où on utilise des agents IA qui peuvent rapidement faire de grosses bêtises et des dépendances qui deviennent de plus en plus risquées, isoler ce que l'on utilise est une bonne approche pour sécuriser son environnement. Je regrette juste qu'il n'existe pas encore un système de permissions plus pratique sur les systèmes d'exploitation modernes...