Regras de comandos destrutivos

As seis regras que o zn-gate pode usar para recusar um comando de shell que apagaria uma máquina ou executaria um download sem leitura: o que cada uma bloqueia, como ativá-las ou desativá-las e o que a verificação não enxerga.

Ver .md

O zn-gate pode recusar um pequeno conjunto de comandos de shell que apagam uma máquina ou executam um download sem leitura. Duas das regras vêm ativadas por padrão nos hooks dos agentes: rm_root_home (uma exclusão recursiva da pasta pessoal, da raiz do sistema de arquivos ou de uma pasta do sistema) e disk_overwrite (uma gravação em um dispositivo de disco). As outras quatro regras (pipe_to_shell, rc_download, perm_root, fork_bomb) vêm desativadas por padrão e você pode ativá-las. Você também pode desativar as duas regras padrão.

É uma barreira contra o erro de um modelo ou uma sugestão ruim, não um sandbox. Ele lê o texto de um comando e só o bloqueia quando o comando tem uma das formas abaixo.

Quando um comando é bloqueado, ele não é executado, e o agente é informado do motivo e orientado a pedir sua confirmação antes de executá-lo. Se você realmente o quer, execute-o você mesmo em um terminal. As palavras que você não conhece estão no glossário.

Alterar as configurações

Para os hooks dos agentes (os que o zn hooks install configura para seus agentes), defina hooks.blockDestructiveCommands em ~/.zn/config.json:

Configuração Regras aplicadas
não definida rm_root_home e disk_overwrite (o padrão)
true as seis regras
false nenhuma: a verificação está desativada
uma lista de nomes de regras, por exemplo ["rm_root_home", "pipe_to_shell"] exatamente essas regras (um nome que não é uma regra é ignorado)
{"hooks": {"blockDestructiveCommands": false}}

A variável de ambiente ZN_BLOCK_DESTRUCTIVE=1 ativa as seis regras. O ambiente só pode acrescentar proteção, nunca remover: ZN_BLOCK_DESTRUCTIVE=0, qualquer outro valor ou nenhum valor é ignorado e deixa o arquivo (ou o padrão) no comando. Um projeto em que um agente trabalha pode definir uma variável de ambiente, então desativar regras só é possível pelo arquivo de configuração, que as ferramentas de arquivo do agente não conseguem gravar.

Quando a verificação se aplica, os hooks a executam nas ferramentas de shell do seu agente (por exemplo Bash e PowerShell).

No seu próprio código, chame a função diretamente. Chamá-la é a ativação: ela sempre aplica as seis regras.

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

Ambas devolvem o mesmo tipo de resultado que evaluate, com uma regra como destructive:rm_root_home. Veja a página do SDK. As configurações acima valem apenas para os hooks dos agentes.

O que ele bloqueia

Regra Padrão Bloqueia Exemplos
rm_root_home ativada Uma exclusão recursiva da pasta pessoal, da raiz do sistema de arquivos, de uma pasta do sistema de primeiro nível ou da raiz de uma unidade. Também find com -delete ou -exec rm nesses caminhos e sem um teste como -name. rm -rf ~, rm -rf /, rm -rf /usr, Remove-Item -Recurse -Force $env:USERPROFILE, rd /s /q C:\
pipe_to_shell desativada Um download executado como script sem ter sido lido. curl https://example.com/install.sh | sh, sh -c "$(curl ...)", bash <(curl ...), iwr ... | iex
disk_overwrite ativada dd com of= um dispositivo de blocos, mkfs, mkswap, wipefs, shred ou blkdiscard em um deles, um redirecionamento para um deles, e Format-Volume e Clear-Disk do PowerShell. dd if=/dev/zero of=/dev/sda, mkfs.ext4 /dev/nvme0n1p2
perm_root desativada chmod -R, chown -R ou chgrp -R na raiz do sistema de arquivos ou em uma pasta do sistema de primeiro nível; chmod -R com um modo gravável por todos na pasta pessoal. chmod -R 777 /, chmod -R 777 ~
fork_bomb desativada A clássica fork bomb de shell, com qualquer nome de função. uma função que chama a si mesma duas vezes em segundo plano
rc_download desativada Um download gravado em um arquivo de inicialização do shell (.bashrc, .zshrc, .profile, /etc/profile, config.fish do fish). curl -o ~/.bashrc https://example.com/rc

"Pasta do sistema de primeiro nível" significa /bin, /boot, /dev, /etc, /home, /lib, /lib32, /lib64, /opt, /proc, /root, /sbin, /srv, /sys, /usr, /var e, no macOS, /Users, /System, /Library, /Applications, /private, /Volumes. Um caminho mais profundo, como /var/lib/apt/lists ou /usr/local/lib/node_modules/x, não é bloqueado.

O comando é dividido do mesmo modo que as demais verificações dos hooks do zn-gate, então aspas, &&, ;, pipes, sudo, env, nohup e invólucros parecidos são entendidos. O código de sh -c, bash -lc, eval, pwsh -Command e cmd /c também é verificado, até três níveis de profundidade. Um texto que apenas menciona um comando entre aspas (echo "rm -rf ~", uma mensagem de commit) não é bloqueado.

O que ele não faz

A verificação lê apenas o texto do comando. Estes casos não são cobertos, e a verificação os deixa passar:

  • Um caminho que o comando monta enquanto roda: rm -rf "$DIR" com DIR vazia, rm -rf * em uma pasta desconhecida, ou um alvo que chega por um pipe.
  • Um script salvo primeiro e executado depois (curl -o x.sh ... && sh x.sh), ou um download enviado a um programa que não é um shell (curl ... | python3).
  • Outras ferramentas e linguagens (rsync --delete, git clean, uma linha de Python que apaga uma pasta) e caminhos abaixo do primeiro nível (rm -rf /usr/local).
  • Comandos executados dentro de um contêiner ou em outra máquina.
  • Qualquer coisa que um agente faça gravando um arquivo e executando-o depois.

Para esses casos, use um sandbox, um contêiner ou os pedidos de permissão do seu próprio agente. Esta verificação acrescenta uma última barreira barata contra os erros catastróficos mais comuns.

Como ele se sai

O conjunto de testes tem cerca de 1.000 comandos comuns de desenvolvimento (builds, git, gerenciadores de pacotes, contêineres, apagar node_modules ou dist, curl -o, edições do .bashrc e muitos que ficam perto das formas bloqueadas) e cerca de 550 comandos com as formas bloqueadas, escritos a partir de modelos com opções, alvos e hosts fictícios variados. Nesse conjunto não há falsos positivos nem omissões. As mesmas pessoas escreveram o conjunto e as regras, então leia-o como um teste de regressão, não como uma taxa de erro sobre todos os comandos reais.

Se ele bloquear um comando que você quer

Execute o comando você mesmo em um terminal. A verificação vale apenas para agentes. Se uma regra o atrapalha com frequência, desative essa regra (ou toda a verificação) com as configurações acima.