Règles sur les commandes destructrices

Les six règles que zn-gate peut utiliser pour refuser une commande shell qui effacerait une machine ou exécuterait un téléchargement sans lecture : ce que bloque chacune, comment les activer ou les désactiver et ce que la vérification ne voit pas.

Voir le .md

zn-gate peut refuser un petit ensemble de commandes shell qui effacent une machine ou exécutent un téléchargement sans lecture. Deux des règles sont activées par défaut dans les hooks des agents : rm_root_home (une suppression récursive du dossier personnel, de la racine du système de fichiers ou d'un dossier système) et disk_overwrite (une écriture sur un périphérique de disque). Les quatre autres règles (pipe_to_shell, rc_download, perm_root, fork_bomb) sont désactivées par défaut et vous pouvez les activer. Vous pouvez aussi désactiver les deux règles par défaut.

C'est un garde-fou contre l'erreur d'un modèle ou une mauvaise suggestion, pas un bac à sable. Il lit le texte d'une commande et ne la bloque que si elle a l'une des formes ci-dessous.

Quand une commande est bloquée, elle ne s'exécute pas, et l'agent est informé de la raison et invité à vous demander confirmation avant de la lancer. Si vous la voulez vraiment, lancez-la vous-même dans un terminal. Les mots que vous ne connaissez pas sont dans le glossaire.

Modifier les réglages

Pour les hooks des agents (ceux que zn hooks install configure pour vos agents), définissez hooks.blockDestructiveCommands dans ~/.zn/config.json :

Réglage	Règles appliquées
non défini	`rm_root_home` et `disk_overwrite` (par défaut)
`true`	les six règles
`false`	aucune : la vérification est désactivée
une liste de noms de règles, par exemple `["rm_root_home", "pipe_to_shell"]`	exactement ces règles (un nom qui n'est pas une règle est ignoré)

{"hooks": {"blockDestructiveCommands": false}}

La variable d'environnement ZN_BLOCK_DESTRUCTIVE=1 active les six règles. L'environnement ne peut qu'ajouter de la protection, jamais en retirer : ZN_BLOCK_DESTRUCTIVE=0, toute autre valeur ou aucune valeur est ignorée et laisse le fichier (ou le réglage par défaut) décider. Un projet sur lequel travaille un agent peut définir une variable d'environnement, donc désactiver des règles n'est possible que depuis le fichier de configuration, que les outils de fichiers de l'agent ne peuvent pas écrire.

Quand la vérification s'applique, les hooks l'exécutent sur les outils shell de votre agent (par exemple Bash et PowerShell).

Dans votre propre code, appelez directement la fonction. L'appeler est l'activation : elle applique toujours les six règles.

Node.js : checkCommand(command) depuis zn-gate/lib/client
Python : check_command(command) depuis zn_gate

Les deux renvoient le même type de résultat que evaluate, avec une règle comme destructive:rm_root_home. Voir la page du SDK. Les réglages ci-dessus ne s'appliquent qu'aux hooks des agents.

Ce qu'il bloque

Règle	Par défaut	Bloque	Exemples
`rm_root_home`	activée	Une suppression récursive du dossier personnel, de la racine du système de fichiers, d'un dossier système de premier niveau ou de la racine d'un lecteur. Aussi `find` avec `-delete` ou `-exec rm` sur ces chemins et sans test tel que `-name`.	`rm -rf ~`, `rm -rf /`, `rm -rf /usr`, `Remove-Item -Recurse -Force $env:USERPROFILE`, `rd /s /q C:\`
`pipe_to_shell`	désactivée	Un téléchargement exécuté comme script sans avoir été lu.	`curl https://example.com/install.sh \| sh`, `sh -c "$(curl ...)"`, `bash <(curl ...)`, `iwr ... \| iex`
`disk_overwrite`	activée	`dd` avec `of=` un périphérique bloc, `mkfs`, `mkswap`, `wipefs`, `shred` ou `blkdiscard` sur l'un d'eux, une redirection vers l'un d'eux, et `Format-Volume` et `Clear-Disk` de PowerShell.	`dd if=/dev/zero of=/dev/sda`, `mkfs.ext4 /dev/nvme0n1p2`
`perm_root`	désactivée	`chmod -R`, `chown -R` ou `chgrp -R` sur la racine du système de fichiers ou un dossier système de premier niveau ; `chmod -R` avec un mode modifiable par tous sur le dossier personnel.	`chmod -R 777 /`, `chmod -R 777 ~`
`fork_bomb`	désactivée	La fork bomb classique du shell, sous n'importe quel nom de fonction.	une fonction qui s'appelle deux fois en arrière-plan
`rc_download`	désactivée	Un téléchargement écrit dans un fichier de démarrage du shell (`.bashrc`, `.zshrc`, `.profile`, `/etc/profile`, `config.fish` de fish).	`curl -o ~/.bashrc https://example.com/rc`

« Dossier système de premier niveau » désigne /bin, /boot, /dev, /etc, /home, /lib, /lib32, /lib64, /opt, /proc, /root, /sbin, /srv, /sys, /usr, /var et, sur macOS, /Users, /System, /Library, /Applications, /private, /Volumes. Un chemin plus profond tel que /var/lib/apt/lists ou /usr/local/lib/node_modules/x n'est pas bloqué.

La commande est découpée comme le font les autres vérifications des hooks de zn-gate, de sorte que les guillemets, &&, ;, les tubes, sudo, env, nohup et les enveloppes semblables sont compris. Le code de sh -c, bash -lc, eval, pwsh -Command et cmd /c est aussi vérifié, jusqu'à trois niveaux de profondeur. Un texte qui ne fait que mentionner une commande entre guillemets (echo "rm -rf ~", un message de commit) n'est pas bloqué.

Ce qu'il ne fait pas

La vérification ne lit que le texte de la commande. Ces cas ne sont pas couverts, et la vérification les laisse passer :

Un chemin que la commande construit pendant son exécution : rm -rf "$DIR" avec DIR vide, rm -rf * dans un dossier inconnu, ou une cible qui arrive par un tube.
Un script enregistré d'abord et lancé plus tard (curl -o x.sh ... && sh x.sh), ou un téléchargement envoyé à un programme qui n'est pas un shell (curl ... | python3).
D'autres outils et langages (rsync --delete, git clean, une ligne Python qui supprime un dossier) et les chemins sous le premier niveau (rm -rf /usr/local).
Les commandes exécutées dans un conteneur ou sur une autre machine.
Tout ce qu'un agent fait en écrivant un fichier puis en l'exécutant.

Pour ces cas, utilisez un bac à sable, un conteneur ou les demandes d'autorisation de votre propre agent. Cette vérification ajoute une dernière barrière peu coûteuse contre les erreurs catastrophiques les plus courantes.

Son efficacité

L'ensemble de tests compte environ 1 000 commandes de développement ordinaires (compilations, git, gestionnaires de paquets, conteneurs, suppression de node_modules ou dist, curl -o, modifications de .bashrc, et beaucoup qui sont proches des formes bloquées) et environ 550 commandes ayant les formes bloquées, écrites à partir de modèles avec des options, cibles et hôtes fictifs variés. Sur cet ensemble, il n'y a ni faux positif ni oubli. Les mêmes personnes ont écrit l'ensemble et les règles : lisez-le comme un test de non-régression, pas comme un taux d'erreur sur toutes les commandes réelles.

S'il bloque une commande que vous voulez

Lancez la commande vous-même dans un terminal. La vérification ne s'applique qu'aux agents. Si une règle vous gêne souvent, désactivez cette règle (ou toute la vérification) avec les réglages ci-dessus.