Drop: una sandbox Linux fatta apposta per coding agent e software poco fidato

Lasciare a un coding agent la possibilità di eseguire comandi direttamente sul proprio sistema Linux è comodo, ma introduce un livello di rischio spesso inaccettabile. Un assistente AI capace di modificare file, installare pacchetti, lanciare script e invocare software dalla shell di sistema può infatti fare danni per un semplice errore, per un comando costruito male o, nello scenario peggiore, dopo aver elaborato istruzioni manipolate tramite prompt injection.

Il progetto Drop nasce per affrontare proprio questo problema: creare una sandbox Linux leggera nella quale far girare agenti AI e software poco fidato senza costruire un container completo e senza lavorare come root.

L’idea poggia su meccanismi che Linux sviluppa da oltre vent’anni. I mount namespace risalgono a Linux 2.4.19, mentre da Linux 3.8 gli utenti sprovvisti di privilegi possono creare user namespace e sfruttarli come base per ulteriori forme di isolamento.

Sono tecnologie sulle quali si appoggiano anche molti sistemi di containerizzazione, ma Drop le usa con un obiettivo diverso: non creare un’altra distribuzione Linux, bensì proteggere il più possibile l’ambiente di lavoro già presente sulla macchina e restringere ciò che il programma può vedere e modificare.

Drop non è un altro Docker: usa il Linux già installato

Il risultato è interessante soprattutto con strumenti come Claude Code e altri agenti capaci di lavorare autonomamente sul filesystem.

Gli sviluppatori di Drop citano esplicitamente l’esecuzione con opzioni come --dangerously-skip-permissions: invece di affidarsi soltanto alle conferme mostrate dall’agente, la barriera si sposta a livello del sistema operativo. Un comando distruttivo diretto verso la home, una lettura di ~/.ssh oppure un tentativo di collegarsi a un servizio che ascolta soltanto su localhost incontrano quindi limitazioni indipendenti dal comportamento del modello AI.

La differenza più evidente rispetto a Docker o Podman riguarda il filesystem della sandbox: Drop non parte da un’immagine contenente una distribuzione separata bensì rende disponibili, in sola lettura, directory di sistema dell’host come /usr, /bin, /sbin, /lib, /lib32 e /lib64. I programmi già installati sul computer rimangono quindi immediatamente utilizzabili.

Con Docker un’immagine descrive anche l’ambiente software in cui l’applicazione deve funzionare; Drop, invece, vuole consentire all’utente di aprire una shell protetta continuando a trovare compilatori, interpreti, editor da terminale e utilità già presenti nella propria installazione.

La configurazione iniziale è volutamente simile al funzionamento di un virtualenv Python. Con drop init si crea un ambiente associato alla directory corrente; drop run apre poi la shell o avvia direttamente il comando richiesto. Se non si assegna esplicitamente un identificativo, Drop lo ricava dal percorso di lavoro.

La vera home sparisce dalla vista del programma

Uno degli aspetti più utili riguarda la gestione della directory personale: Drop costruisce tramite un mount namespace una propria vista del filesystem. La home effettiva dell’utente non compare nella sandbox e al suo posto viene montata una directory dedicata memorizzata sotto ~/.local/share/drop/envs/.

Se all’interno della sandbox un agente eseguisse per errore il comando rm -rf ~ (elimina ricorsivamente e senza chiedere conferma tutto il contenuto della home dell’utente), l’attività sarebbe espletata all’interno della home dell’ambiente Drop e non su quella reale.

Analogamente, un attacco di tipo prompt injection che suggerisse di leggere ~/.ssh non dovrebbe trovare le chiavi SSH dell’utente, a meno che qualcuno non le abbia deliberatamente esposte tramite la configurazione.

Drop applica una logica simile anche a /var e /tmp, che ricevono spazi dedicati. Directory come /proc, /sys, /run e /dev sono invece predisposte all’interno dell’ambiente; per i dispositivi, l’accesso predefinito si limita essenzialmente a elementi basilari come /dev/null, /dev/zero, /dev/full, /dev/random e /dev/urandom.

La sandbox non rende intoccabili i file del progetto

Quando si esegue drop init dentro una directory di lavoro, Drop concede per impostazione predefinita all’ambiente accesso in lettura e scrittura alla directory corrente; la sottodirectory .git, invece, è esposta in sola lettura.

È una scelta logica per un coding agent, che deve poter modificare sorgenti, creare file e applicare patch: la conseguenza, tuttavia, è che la sandbox non può impedire all’agente di danneggiare i file ai quali l’utente ha esplicitamente concesso accesso in scrittura. Drop protegge la home e le altre risorse non esposte, ma non può neutralizzare – ad esempio – un rm -rf lanciato dentro il progetto sul quale l’agente sta lavorando.

Interessante anche il trattamento riservato a variabili d’ambiente e servizi localhost. Molti sviluppatori conservano token API, credenziali cloud e altre informazioni “delicate” all’interno di variabili esportate dalla shell; Drop non le trasferisce automaticamente tutte nella sandbox ma consente di specificare quelle ammesse tramite exposed_vars.

Lo stesso approccio è utilizzato per la rete: i servizi TCP e UDP in ascolto sull’host locale non sono raggiungibili per impostazione predefinita e devono essere autorizzati esplicitamente. Su una workstation possono trovarsi database, server di sviluppo, debugger e interfacce amministrative che ascoltano su 127.0.0.1 proprio perché normalmente considerate risorse accessibili soltanto dall’utente locale.

Come installare Drop su Linux

Drop richiede come dipendenza passt/pasta, utilizzato per fornire la rete agli ambienti isolati. Su Debian e Ubuntu basta installare il pacchetto passt:

sudo apt-get install passt

Su Fedora il comando equivalente è:

sudo dnf install passt

mentre su Arch Linux si può usare:

sudo pacman -S passt

Il metodo più immediato per installare Drop consiste quindi nello scaricare il binario precompilato appropriato. Il progetto pubblica versioni per amd64 e arm64. La procedura suggerita dalla documentazione ufficiale determina automaticamente l’architettura e copia il programma in ~/.local/bin:

ARCH=$(uname -m | sed 's/x86_64/amd64/; s/aarch64/arm64/')
curl -o drop -L https://github.com/wrr/drop/releases/latest/download/drop-linux-$ARCH
install drop ~/.local/bin/

Se ~/.local/bin non fosse già compresa nella variabile PATH, è necessario aggiungerla alla configurazione della shell. In alternativa, chi dispone di Go 1.25 o versione successiva può installare direttamente Drop con:

CGO_ENABLED=0 go install github.com/wrr/drop/cmd/drop@latest

Su alcune distribuzioni serve un passaggio aggiuntivo. Ubuntu 24.04 e versioni successive applicano restrizioni AppArmor durante la creazione degli user namespace da parte delle applicazioni. Drop documenta quindi la creazione di un profilo AppArmor dedicato che autorizzi l’uso di userns.

Fedora presenta invece una particolarità analoga sul versante SELinux: la policy standard può impedire a pasta di accedere ai riferimenti dei namespace sotto /proc/<pid>/ns. Anche in questo caso il progetto fornisce una piccola policy da installare. Conviene quindi consultare le istruzioni specifiche per la distribuzione prima di concludere che un errore di avvio dipenda da Drop.

Come creare e usare una sandbox con Drop

L’utilizzo quotidiano è molto semplice. Supponiamo di avere un progetto nella directory ~/project. Ci si sposta al suo interno e si inizializza l’ambiente:

cd ~/project
drop init

Drop crea un file di configurazione TOML sotto ~/.config/drop/ e associa l’ambiente al percorso corrente. Se non si specifica un nome, l’identificativo deriva proprio dalla directory dalla quale è stato eseguito il comando.

A quel punto basta digitare:

drop run

Se non viene indicato nessun altro comando, Drop avvia la shell definita dalla variabile $SHELL. Ci si ritrova quindi apparentemente nello stesso ambiente di prima, con lo stesso nome utente e nello stesso percorso, ma all’interno della sandbox. Un ps aux, ad esempio, mostra soltanto i processi appartenenti all’ambiente Drop e non quelli dell’intero host.

È possibile anche avviare direttamente un programma senza entrare prima nella shell. Per esempio:

drop run python script.py

oppure, nel caso di un coding agent:

drop run claude --dangerously-skip-permissions

In quest’ultimo scenario Claude Code continua a lavorare sulla directory del progetto ma opera con le restrizioni imposte da Drop. Le autorizzazioni non dipendono quindi soltanto dalle richieste di conferma dell’agente: è il sistema operativo a limitare filesystem, processi, dispositivi, variabili d’ambiente e accesso ai servizi locali.

Se si preferisce assegnare un nome esplicito all’ambiente, si può scrivere:

drop init claude

e successivamente richiamarlo con:

drop run -e claude

Gli ambienti sono persistenti: chiudere la shell non cancella automaticamente la home isolata né i file creati al suo interno. Con drop ls si visualizzano gli ambienti esistenti; drop rm permette invece di eliminarli insieme ai relativi dati. È quindi più corretto considerarli facilmente eliminabili piuttosto che temporanei in senso stretto.

gVisor per aumentare ulteriormente l’isolamento

Di default Drop utilizza il runtime native: processi e filesystem risultano isolati tramite i namespace Linux, ma le system call raggiungono ancora il kernel dell’host.

Chi intendesse innalzare ulteriormente la barriera può installare gVisor e il relativo runtime runsc, quindi avviare un programma con:

drop run --runtime gvisor comando

gVisor è una tecnologia di sandboxing sviluppata da Google che aggiunge un ulteriore strato di isolamento tra un’applicazione e il kernel Linux dell’host.

Invece di lasciare che il programma esegua direttamente le proprie system call sul kernel reale, gVisor le intercetta e le gestisce tramite un kernel in user space chiamato Sentry. In questo modo si riduce molto la superficie del kernel host direttamente esposta a software potenzialmente malevolo.

Con gVisor le chiamate di sistema dell’applicazione passano attraverso il kernel in user space del progetto Google anziché raggiungere direttamente il kernel Linux host.

L’isolamento cresce, ma c’è un prezzo da pagare: alcune applicazioni possono manifestare problemi di incompatibilità e le operazioni molto intensive in termini di system call possono subire un certo overhead. Il runtime può comunque essere cambiato anche su ambienti Drop già esistenti, quindi è possibile usare native per il lavoro quotidiano e riservare gVisor al software del quale ci si fida meno.