F FabGPT-FAQ

Come si filtrano le syscall pericolose (seccomp, gVisor)?

AI e LLM 2 min lettura Runbook verificato

Quando esegui codice non fidato – un agente AI che lancia comandi, un container, codice generato – il rischio finale è che una syscall (la richiesta di un programma al kernel) faccia qualcosa di pericoloso o buchi l'isolamento (container escape). Gli strumenti che lo impediscono:

  • seccomp (secure computing mode) – filtra quali syscall un processo può fare: si definisce una allowlist (il container ha bisogno solo di queste 50 syscall, non di tutte le 300+), e ogni chiamata fuori lista viene bloccata. Riduce drasticamente la superficie del kernel esposta
  • gVisor – un approccio più radicale: un kernel applicativo in user-space che intercetta le syscall del carico e le gestisce lui, senza passarle direttamente al kernel reale. Isolamento molto più forte di un container normale, con un po' di overhead
  • Kata Containers – container che girano dentro micro-VM leggere: l'isolamento di una VM con l'ergonomia di un container

La scala di isolamento, dal più leggero al più forte: seccomp+namespace (container normale) → gVisor → micro-VM (Kata) → VM piena. Più forte l'isolamento, più overhead: si sceglie in base a quanto è non fidato ciò che esegui. Per un agente che esegue codice arbitrario, gVisor o micro-VM usa-e-getta sono la scelta prudente – più egress chiuso e permessi minimi. È defense in depth al confine tra software e kernel.

Hai una domanda specifica su questo tema?

Interroga direttamente il motore FabGPT-FAQ con risposta in tempo reale.