Uma coisa que eu olharia é como fica a regra quando o processo é um interpretador. Muito servidor MCP e ferramenta de agente roda via npx ou uvx, então quem abre a conexão é sempre o node ou o python. Se a regra for por executável, liberar o node uma vez libera tudo que roda em cima dele. Dá pra diferenciar pela linha de comando ou pelo processo pai? Pro caso de vigiar agente que o Oletros citou isso faz bastante diferença.
1
1
Boa pergunta — você tocou num ponto real.
Hoje o Snitch já diferencia na atribuição: a aba de processos mostra a linha de comando completa e a cadeia de pais, então node /…/mcp-server.js aparece distinto de outro node qualquer.
Mas as regras de bloqueio casam por executável — é a mesma limitação do WFP ALE_APP_ID no Windows e do owner match do iptables: a camada de kernel filtra por identidade do binário, não por argv. Ou seja, liberar node hoje libera tudo que roda nele — exatamente o problema que você descreveu com npx/uvx.
O caminho honesto que eu vejo:
- Regras de alerta por cmdline (regex): viável já — cada spawn do npx gera um PID novo com argv distinto, resolvemos PID→cmdline no momento do evento e cacheamos
- Bloqueio por cmdline: aplicável no caminho de veredito em userspace (NFQUEUE/ask-mode no Linux); no Windows o WFP não expõe argv, seria resolução por PID — mais frágil mas possível
- Parent process matching: a cadeia já é coletada, falta expor como campo de regra
Ressalva honesta: argv é controlável pelo próprio processo, então é heurística boa pra distinguir agentes/MCPs, não fronteira de segurança rígida. Pra isso o ideal seria eBPF/cgroup no Linux — já temos eBPF no roadmap.
Abri a issue #61 pra trackear: github.com/aixisstudio/Snitch/issues/61 — valeu pelo olhar afiado, é exatamente o tipo de feedback técnico que a gente precisa.
1
valeu por abrir a issue. no Linux tem um meio-termo antes do eBPF que talvez ajude: subir cada servidor MCP no próprio scope com systemd-run --user --scope e casar a regra pelo cgroup (o iptables tem -m cgroup --path no cgroup v2, e o nftables tem socket cgroupv2). aí o node de um MCP e o node do outro ficam separados sem depender do argv, que o próprio processo consegue mudar. o lado chato é que depende de como o cliente sobe o processo, então ia precisar de um wrapper no comando do MCP.