Aprovações de exec avançadas no OpenClaw

A página principal de aprovações de execução explica a política e o pedido de aprovação. A página avançada é onde ficam as arestas afiadas: quais binários podem pular a lista de permissões porque só conseguem ler o stdin, como o gateway vincula um comando de interpretador aos arquivos exatos que ele vai executar, de qual escopo um painel precisa para aprovar qualquer coisa e como um pedido chega a um canal de chat e volta como decisão. Aqui está essa página, condensada.

Safe bins

• A configuração de safe bins lista binários só de stdin que rodam no modo allowlist sem entradas explícitas, por padrão cut, uniq, head, tail, tr e wc; eles rejeitam argumentos posicionais de arquivo e tokens com cara de caminho, tratam os argumentos como texto literal, sem globbing nem expansão de variáveis, e a validação é determinística apenas a partir da forma dos argumentos: flags longas desconhecidas e abreviações ambíguas são rejeitadas em modo fail-closed, e flags curtas não reconhecidas caem na política de aprovação.
• grep e sort não são safe bins padrão e mantêm entradas explícitas na lista de permissões para seus fluxos que não usam stdin, com o grep em modo safe-bin recebendo o padrão de busca apenas pela flag de padrão explícita; awk, sed e jq são sempre negados como safe bins porque sua semântica não pode ser validada como somente stdin; interpretadores e runtimes nunca devem ser adicionados, safe bins personalizados exigem um perfil explícito, a auditoria alerta sobre binários de interpretador sem perfil e a correção do doctor pode gerar a estrutura de perfis personalizados vazios, para serem restringidos depois.
• Safe bins precisam ser resolvidos a partir de diretórios confiáveis, os dois caminhos padrão do sistema, e entradas do caminho de busca nunca são confiáveis automaticamente, então caminhos de gerenciadores de pacotes entram explicitamente na lista de diretórios confiáveis; a lista de flags negadas por perfil bloqueia opções que leem arquivos, como as flags recursiva e de arquivo do grep, as opções de saída e de lista de arquivos do sort, o follow no tail e a opção de lista de arquivos no wc.
• O encadeamento de shell é permitido quando cada segmento de nível superior satisfaz a lista de permissões, redirecionamentos continuam sem suporte, a substituição de comando é rejeitada mesmo entre aspas duplas, wrappers de shell reduzem as sobrescritas de ambiente da solicitação a uma lista pequena, decisões allow-always persistem o executável interno por trás de wrappers transparentes e desembrulham applets de multiplexadores de shell, e a avaliação inline estrita mantém o eval inline sujeito a revisão quando há interpretadores na lista de permissões.

A entrega na sessão controla apenas onde o pedido aparece. Ela não autoriza, por si só, todos os participantes daquele chat a aprovar.

Vinculação de interpretadores e o escopo approvals

Execuções de interpretador baseadas em aprovação são deliberadamente conservadoras. Os argumentos exatos, o diretório de trabalho e o ambiente são vinculados; no gateway, toda a cadeia externa de despacho, cada executável wrapper e o final, é vinculada antes da revisão e verificada de novo antes do lançamento, os executáveis protegidos pelo caminho real e os graváveis também por hash de conteúdo, então um novo executável que apareça antes no caminho de busca faz a execução ser negada. Scripts diretos e arquivos de runtime são vinculados a um único snapshot de arquivo, wrappers comuns de gerenciadores de pacotes são desembrulhados primeiro, e, quando o gateway não consegue identificar exatamente um arquivo local (scripts de pacote, formas de eval ou cadeias de loaders), a execução baseada em aprovação é negada em vez de fingir que a cobre. No modo automático, o revisor só lida com cadeias totalmente vinculadas: wrappers de comando de shell, atribuições de ambiente, applets e despacho de builtins pulam a revisão automática e seguem o caminho humano de uso único, wrappers de shell de login e interativos precisam de um humano porque seus arquivos de inicialização ficam fora da vinculação, e opções interativas de carregamento de código continuam negadas. Quando a aprovação é necessária, a ferramenta devolve imediatamente um ID de aprovação; uma decisão que nunca chega esgota o tempo limite e aparece como negação de comando no host, com a sessão de origem retomada para que o agente veja que o comando não rodou, e aprovações pendentes expiram após 30 minutos. Resolver uma aprovação exige o escopo dedicado approvals, que write não engloba, e a documentação o descreve como uma autoridade equivalente a execução remota, a ser concedida de forma deliberada mesmo a uma pequena interface de aprovação.

Encaminhamento para o chat

• O bloco de encaminhamento de aprovações de execução envia os pedidos a qualquer canal de chat pelo pipeline de saída normal, no modo session, targets ou both, com filtros de agente e de sessão e alvos formados por canal e destinatário; o agente só repassa um comando approve a partir de uma aprovação realmente pendente, com seu ID exato, um ID solto ou inventado não aprova nada, uma concessão allow-once cobre um comando, e o mesmo comando resolve aprovações de plugin quando o ID não é de uma aprovação de exec pendente, com a família de plugins configurada de forma independente.
• O chat de origem pode aprovar por padrão no Slack, no Matrix, no Teams e em superfícies de entrega semelhantes, enquanto Discord, Telegram e o bot do QQ usam suas listas de aprovadores resolvidas mesmo no mesmo chat; clientes nativos de aprovação acrescentam mensagens diretas aos aprovadores, distribuição no chat de origem e cartões interativos, ativados por canal com aprovadores resolvíveis, com o Telegram usando por padrão o modo automático e mensagens aos aprovadores, e um cartão que não chega a nenhum alvo recorre a um aviso no mesmo chat com o comando exato.
• Um alvo pode levar um ID de conta, para enviar por uma conta de bot específica, e um ID de thread, para ficar dentro de um tópico de fórum; os apps móveis oficiais revisam aprovações pendentes em uma conexão de admin ou quando o dispositivo de aprovações deles foi o alvo, relendo o registro quando uma confirmação se perde; e o caminho do macOS passa por um socket do mesmo usuário, com um token, um desafio e um tempo de vida curto.

As aprovações de execução do OpenClaw são a política principal que esta página estende, e o guia da sandbox do OpenClaw, a fronteira que a documentação prefere para fluxos que a vinculação não consegue cobrir.

Por que a via rápida é estreita

Todo o design de safe bins se apoia em uma propriedade: um binário que só consegue ler o próprio stdin não consegue exfiltrar um arquivo que a política não pretendia expor. Todas as regras decorrem disso: a rejeição de caminhos posicionais, os argumentos literais, as flags de arquivo negadas, a proibição de interpretadores e do jq, e os diretórios confiáveis que barram um binário imitador que apareça antes no caminho de busca. No momento em que uma ferramenta pode abrir arquivos ou avaliar código, a documentação a manda para a lista de permissões, com um pedido de aprovação. O Telegram na Diali e o Slack na Diali são dois canais da Diali onde os pedidos encaminhados podem chegar.

Na Diali

Na Diali, a configuração de execução é gerada a partir do painel e substituída a cada nova versão, e o ambiente de cada cliente é uma fronteira própria. O OpenClaw hospedado na Diali descreve o assistente hospedado, e a página de segurança da Diali, os controles em torno de cada comando que ele executa.

• Safe bins só leem stdin; interpretadores nunca se qualificam.
• Execuções de interpretador vinculam a cadeia inteira ou são negadas.
• Aprovar exige o escopo approvals, não write.