Riepilogo Tecnico: AI Code Sandboxes: Uno Studio Comparativo di Sicurezza (Parte 1)

Definizione del Problema

Il documento affronta la sfida critica dell'isolamento a livello di engine per gli agenti AI che eseguono codice non fidato. Sebbene il "sandboxing" sia una categoria di difesa standard nella letteratura sulla sicurezza dell'IA agente, manca una misurazione profonda a livello di engine che confronti come diversi prodotti isolino il codice guest dal kernel host. L'urgenza è dettata dalla ricerca sulle "capacità pericolose" (dangerous capability), la quale indica che gli agenti AI sono già in grado di eseguire attacchi informatici multi-step (ad esempio, completando 22 su 32 step di un attacco alla rete aziendale) entro gli attuali budget computazionali. Lo studio si concentra sul modello di minaccia T0.H2.N2: un operatore single-tenant che esegue codice non fidato sulla propria infrastruttura, dove l'operatore si fida dell'infrastruttura ma non del codice. L'obiettivo è misurare come cinque specifici prodotti di sandbox AI (arrakis, e2b, microsandbox, gvisor, daytona) prevengano la fuga dal kernel host (host kernel escape) e la perdita di informazioni (information leakage).

Metodologia

Lo studio impiega un framework comparativo cross-class a sei assi che misura le proprietà determinate dall'engine sottostante (microVM, kernel in userspace o contenitore OCI). La metodologia proibisce esplicitamente il punteggio composito o il ranking complessivo, fornendo invece ordinamenti per singolo asse e una matrice di qualificazione del modello di minaccia.

I Sei Assi:

1. Superficie di Attacco Host (1.1): Misura l'impronta del runtime/mediatore (L2) sul kernel host (L1) tramite conteggi dei syscall via strace, soffitti di filtri seccomp e raggiungibilità delle primitive (14 specifiche primitive di kernel-LPE/container-escape).
2. Perdita di Informazioni (1.2): Misura quali dati identificativi dell'host (CPU, RAM, versione del kernel, seriali disco) sono esposti al guest tramite letture da /proc, /sys e /dev.
3. Impilabilità della Difesa in Profondità (1.3): Valuta se un operatore può stratificare ulteriori hardening di Linux (seccomp, AppArmor, user namespaces, ecc.) sopra i default dell'engine.
4. Cronologia Pubblica CVE (1.4): Analizza gli ultimi 24 mesi di CVE per ogni engine, classificandoli per impatto (Escape, HostLeak, HostDoS).
5. Cadenza delle Patch (1.5): Misura il ritardo temporale tra la patch upstream e la disponibilità a livello di prodotto, distinguendo tra modelli di disclosure coordinata e modelli "silent-fix-first".
6. Postura di Fuzzing Upstream (1.6): Valuta la presenza di fuzzing pubblico continuo, harness in-tree e attribuzione per CVE alla scoperta tramite fuzzer.

Configurazione Sperimentale:

• Host: Nodo bare-metal singolo Hetzner (Ubuntu 24.04, Kernel 6.8.0).
• Prodotti: Cinque prodotti mappati su tre classi di engine:
  • MicroVMs: arrakis (Cloud Hypervisor), e2b (Firecracker), microsandbox (libkrun).
  • Userspace Kernel: gvisor (runsc).
  • OCI Container: daytona (runc via Docker-CE).
• Verifica: Utilizza test di "probra" (pass/fail), "misurazione" (conteggio syscall) e "ricerca documentale" (analisi CVE/Fuzzing).

Contributi Chiave e Risultati

1. Classi di Engine vs. Varianza dei Prodotti

Sebbene le classi di engine (microVM vs. userspace kernel vs. container) si separino nettamente sugli assi architettonici (superficie di attacco, leakage), i prodotti all'interno della stessa classe non lo fanno. Le configurazioni e le policy di pinning a livello di prodotto sono spesso differenziatori più significativi rispetto alla classe di engine stessa.

• Esempio: arrakis (microVM) ha una policy di patch "congelata" (471+ giorni), mentre daytona (container) è "attuale" sulle patch, invertendo la gerarchia di sicurezza attesa basata solo sulla classe di isolamento.

2. Superficie di Attacco e Raggiungibilità delle Primitive

• gVisor ha la superficie di attacco più stretta (5/14 primitive raggiungibili) grazie al suo kernel in userspace che intercetta i syscall.
• Firecracker (e2b) ha il soffitto seccomp più stretto (55 syscall) ma presenta comunque 2 nuovi CVE di classe Escape nella finestra del 2026, provando che una superficie ridotta non garantisce lo zero bug nei percorsi esercitati.
• arrakis espone un'interfaccia /dev/kvm live al guest, consentendo la virtualizzazione nidificata senza escalation di privilegi, espandendo significativamente la sua superficie di kernel-LPE rispetto ad altre microVM.

3. Dominanza della Propagazione delle Patch

Lo studio rileva che la policy di pinning lato prodotto è la variabile dominante per l'operatore, aggregando circa 0 giorni di ritardo per le disclosure coordinate upstream ma spaziando da 0 a 471+ giorni a valle.

• arrakis e e2b (self-hosted) sono "congelati" su versioni precedenti dell'engine, rimanendo non patchati contro recenti CVE critiche (es. CVE-2026-45782 per arrakis, CVE-2026-5747 per e2b).
• gvisor segue un modello "silent-fix-first" dove le correzioni vengono rilasciate mesi prima dell'assegnazione della CVE, risultando in un lag negativo (gli operatori ricevono le fix prima della disclosure pubblica).

4. Postura di Fuzzing e Rischi "Non Misurati"

• gVisor è l'unico engine con un fuzzer pubblico continuo (syzkaller) e harness in-tree.
• Firecracker e libkrun non hanno alcuna infrastruttura di fuzzing upstream.
• Risultato Critico: La combinazione di "Classe MicroVM" (forte isolamento) e "Continuous Public Fuzzer" (forte rilevamento dei bug residui) è non occupata in questo set.
• libkrun (microsandbox) è strutturalmente non misurato: ha 0 CVE pubblicate e nessun fuzzer upstream. Il paper sostiene che "0 CVE" qui sia un'assenza di segnale, non una prova di solidità, creando un profilo di rischio "strutturalmente non misurato".

5. Perdita di Informazioni (Information Leakage)

• Le MicroVM generalmente perdono 0–1 identificatori host (stringhe CPU configurabili).
• gVisor perde 2 identificatori (RAM totale, prodotto BIOS) a causa di gap nell'implementazione del suo /proc sintetico.
• daytona perde 10 identificatori, inclusi seriali disco e firme complete del kernel, a causa dell'architettura a kernel condiviso.

Significato e Rivendicazioni

Il paper afferma che non è possibile né proposto un ranking complessivo. Invece, fornisce una matrice di qualificazione del modello di minaccia che permette agli operatori di rispondere a quattro sotto-domande specifiche:

1. Resistenza all'Escape: Il codice può sfuggire al kernel host?
2. Resistenza alla Ricognizione: Cosa può apprendere il codice riguardo all'host?
3. Compatibilità con l'Hardening: L'operatore può aggiungere livelli di hardening Linux?
4. Propagazione delle Patch: L'operatore riceve le correzioni tempestivamente?

Conclusioni Chiave:

• I compromessi sono inevitabili: La classe di isolamento più forte (microVM) non correla automaticamente con la postura di bug residui più forte (fuzzing). Gli operatori devono scegliere tra "isolamento più forte" (microVM) e "residui più superficiali" (gVisor).
• I default del prodotto contano: I punti di forza dell'engine (es. seccomp per thread di Cloud Hypervisor) possono essere annullati dai default del prodotto (es. l'esposizione di nested-KVM di arrakis o il pin congelato di e2b).
• Il gap "Non Misurato": L'assenza di CVE e fuzzing in libkrun crea un profilo di rischio che non può essere inferito come "sicuro" o "non sicuro", ma solo come "non misurato".
• Spostamento Metodologico: Lo studio va oltre il semplice "replay" delle CVE per passare a una meta-analisi delle proprietà architettoniche, della cadenza delle patch e dell'investimento nel fuzzing per descrivere lo stato attuale della sicurezza delle sandbox AI.

Il paper funge da baseline per la misurazione a livello di engine, identificando specifici gap di configurazione a livello di prodotto (come la nested-KVM di arrakis o l'hardcoding di Privileged: true in daytona) che richiedono attenzione immediata da parte dell'operatore o rimedio upstream.