Drop è un programma per Linux che crea ambienti isolati in cui far girare comandi, script e agenti di programmazione, senza bisogno dei permessi di root e senza costruire un container. Il funzionamento ricalca quello dei virtualenv di Python, cioè si crea un ambiente, ci si entra e si lavora come sempre, con la differenza che qui l’isolamento è una regola imposta dal kernel. Dentro l’ambiente trovi la tua distribuzione, i tuoi programmi, il tuo nome e i tuoi file di configurazione, mentre la cartella ~/.ssh, i token e il resto della home semplicemente non esistono.
Il progetto è scritto in Go da Jan Wrobel, è rilasciato con licenza Apache 2.0 e la versione più recente, la 0.2.1, porta la data del 23 agosto 2026. È stato presentato su Hacker News proprio in questi giorni, e l’interesse che ha raccolto è facile da capire.
Nel 2026 sulle macchine di chi sviluppa girano due categorie di software che meritano poca fiducia, ovvero i pacchetti scaricati da npm e PyPI e gli agenti AI a cui si concede di eseguire comandi senza chiedere conferma. Entrambi lavorano con il tuo account e vedono tutto quello che vedi tu. Drop prova a spezzare questo legame con uno strumento che si installa in due minuti e che, a differenza di Docker, non ti costringe a ricostruire da zero l’ambiente di lavoro.
Il problema di npm
Quando si installa un pacchetto JavaScript, npm può eseguire degli script definiti dal pacchetto stesso, i cosiddetti lifecycle script, come preinstall e postinstall. Nascono per compiti legittimi, come compilare un modulo nativo, ma in pratica permettono a chiunque pubblichi un pacchetto di far girare codice arbitrario sul computer di chi lo installa, con gli stessi permessi dell’account in uso. Lo stesso discorso vale, con meccanismi diversi, per molti pacchetti Python.
Alla fine di marzo 2026, un attaccante ha preso il controllo dell’account di uno dei manutentori di axios, una delle librerie più scaricate in assoluto, e ha pubblicato due versioni contenenti una dipendenza fasulla che all’installazione scaricava un trojan per Windows, macOS e Linux. Le versioni sono rimaste online per circa tre ore.
Ad agosto Microsoft ha documentato la campagna ChainDrop, un worm che ha infettato oltre 400 pacchetti npm, tra cui keyv e cache-manager, e che una volta eseguito raccoglieva token npm e GitHub, chiavi SSH, cronologia della shell e credenziali cloud. Con i token rubati ripubblicava poi in automatico i pacchetti della vittima con il codice malevolo dentro, così da propagarsi da solo.
Il punto che questi episodi mettono in luce è semplice. Il malware non ha bisogno di sfruttare alcuna vulnerabilità: gli basta leggere file che il tuo account può già leggere. La cartella ~/.ssh, il file ~/.npmrc con il token di pubblicazione, ~/.aws/credentials, le variabili d’ambiente con le chiavi API sono tutte lì, a disposizione di qualsiasi processo lanciato da te.
Gli agenti di programmazione aggiungono un secondo fronte allo stesso problema. Chi usa Claude Code, Codex o strumenti simili sa bene che l’agente rende al meglio quando può lanciare comandi senza chiedere il permesso a ogni passo. In quella modalità l’agente installa dipendenze, esegue test e scarica script, e un’istruzione malevola nascosta in un README o in una pagina web può convincerlo a fare cose che non gli hai chiesto. La domanda utile non è se l’agente sbaglierà, ma cosa può toccare nel momento in cui sbaglia.
Cosa vede un programma chiuso dentro Drop
Per costruire il recinto, Drop usa i namespace di Linux, lo stesso meccanismo del kernel su cui si basano Docker e Podman. Un namespace è una sorta di vista privata su una risorsa del sistema. Un processo confinato in un proprio namespace dei processi vede soltanto i processi del suo gruppo; un processo confinato in un proprio namespace di mount vede soltanto le cartelle che gli sono state montate, e così via per la rete, gli utenti, i mount e la comunicazione tra processi.
Drop li combina tutti e, prima di avviare il programma, riduce o rimuove anche le capability, cioè specifici privilegi del kernel che potrebbero consentire al processo di compiere operazioni amministrative. Il risultato è un processo che opera con i privilegi dell’utente, ma con accesso limitato al filesystem, alla rete, ai processi e alle altre risorse del sistema.
La parte più interessante è il modo in cui viene composto il filesystem. Le cartelle di sistema come /usr, /bin e /lib arrivano dall’host in sola lettura, quindi dentro l’ambiente hai a disposizione tutti i programmi installati sulla tua distribuzione, dal compilatore al linter. La cartella /etc è montata con un overlay, per cui le eventuali modifiche finiscono in una copia privata dell’ambiente. La home invece è nuova e appartiene all’ambiente, salvata in ~/.local/share/drop/envs/<nome>/home, e al suo interno compaiono soltanto i file che hai scelto di esporre, in sola lettura.
Questa scelta della sola lettura non è casuale. Se un programma nel recinto potesse scrivere nel tuo ~/.bashrc, basterebbe aggiungere una riga per far eseguire un comando qualsiasi fuori dal recinto la prossima volta che apri un terminale. La cartella del progetto in cui lanci Drop è accessibile in lettura e scrittura, ma la sua sottocartella .git resta in sola lettura. Il motivo è che dentro .git vivono gli hook e la configurazione del repository, e un hook scritto dal recinto partirebbe al tuo prossimo commit fatto fuori.
Sul fronte della rete, Drop si appoggia a pasta, il componente del progetto passt che Podman usa da tempo per la rete dei container senza privilegi. La modalità predefinita consente di raggiungere Internet, ma impedisce all’ambiente di accedere ai servizi esposti sull’interfaccia locale dell’host, come un database locale, il pannello del router o Ollama.
Installazione su Ubuntu, Fedora e Arch
L’unica dipendenza da installare è il pacchetto passt, disponibile nei repository di tutte le distribuzioni principali.
sudo apt-get install passt # Debian e Ubuntu
sudo dnf install passt # Fedora
sudo pacman -S passt # Arch
Drop invece è un binario unico, compilato staticamente, che basta scaricare dalla pagina delle release su GitHub e copiare in una cartella presente nel PATH. Le architetture supportate sono x86_64 e ARM a 64 bit.
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/
drop update --check
Chi ha Go 1.25 o successivo può anche compilarlo con CGO_ENABLED=0 go install github.com/wrr/drop/cmd/drop@latest.
Su due distribuzioni serve un passaggio in più. Ubuntu, a partire dalla 24.04, impedisce ai programmi non autorizzati di creare user namespace senza privilegi, una restrizione introdotta proprio perché questa funzione del kernel è stata in passato un bersaglio frequente degli attacchi. Per sbloccare Drop bisogna quindi scrivere un piccolo profilo AppArmor che lo autorizzi esplicitamente.
DROP_BIN=$(which drop) && sudo tee /etc/apparmor.d/drop << EOF
abi <abi/4.0>,
include <tunables/global>
profile drop $DROP_BIN flags=(unconfined) {
userns,
}
EOF
sudo systemctl reload apparmor.service
Su Fedora il problema è invece SELinux, che senza una regola dedicata ferma pasta con l’errore netns dir open: Permission denied. La documentazione ufficiale fornisce un modulo di policy da compilare con checkmodule e caricare con semodule, e vale la pena copiarlo da lì senza modificarlo.
A questo punto il primo ambiente si crea dalla cartella del progetto.
cd ~/progetti/webapp
drop init
drop run
Il comando drop init genera due file in ~/.config/drop. Il primo, base.toml, è condiviso da tutti gli ambienti e contiene l’elenco dei file di configurazione esposti e delle variabili d’ambiente consentite. Il secondo porta il nome dell’ambiente e contiene le impostazioni specifiche. Con drop run si apre una shell con il prefisso (drop) nel prompt, mentre drop ls elenca gli ambienti esistenti e drop rm nome li cancella insieme a tutto ciò che contengono. Il consiglio è di aprire subito base.toml e leggerlo riga per riga, perché la configurazione predefinita espone per esempio ~/.gitconfig, che può contenere informazioni sensibili o riferimenti a strumenti incaricati di gestire le credenziali.
Un agente con i privilegi dell’utente, ma isolato in un recinto
Lo scenario per cui Drop dà il meglio è proprio quello dell’agente lasciato libero. L’agente va installato dentro l’ambiente, così i suoi file finiscono nella home privata e non sporcano quella vera. Con Claude Code, per esempio, la sequenza è questa.
cd ~/progetti/webapp
drop init agente
drop run -e agente
curl -fsSL https://claude.ai/install.sh | bash
claude --dangerously-skip-permissions
Il login viene salvato nella home dell’ambiente, e al primo avvio occorre ripeterlo. Da qui in avanti l’agente può installare dipendenze, lanciare test e modificare il codice, ma se prova a leggere ~/.ssh trova una cartella che non esiste, e se un pacchetto compromesso cerca il token di npm non trova il file. Tutti gli strumenti già presenti sul sistema restano disponibili, quindi l’agente può chiamare ruff, cargo o pytest senza installare nulla.
Le esigenze di un progetto si risolvono nel file TOML dell’ambiente. Supponi di voler dare all’agente l’accesso a un modello locale servito da Ollama sulla porta 11434, di voler vedere dal browser il server di sviluppo sulla porta 5173 e di voler nascondere il file .env che contiene le chiavi del database di prova. Il file ~/.config/drop/agente.toml diventa così.
extends = "./base.toml"
blocked_paths = ["~/progetti/webapp/.env"]
[net]
tcp_host_ports = ["11434"]
tcp_published_ports = ["5173"]La voce tcp_host_ports apre verso il recinto una o più porte TCP locali dell’host, lasciando chiuse tutte le altre, mentre tcp_published_ports fa il percorso inverso e rende raggiungibile dall’host un servizio avviato nel recinto, legato per impostazione predefinita al solo indirizzo 127.0.0.1. Se il server di sviluppo non risponde, di solito è perché ascolta soltanto sull’interfaccia di loopback del recinto; con Vite basta avviarlo usando l’opzione --host.
Esistono anche le varianti da riga di comando, utili per le eccezioni che valgono una volta sola. Per esempio drop run --net off npm test lancia i test con la rete spenta, una buona abitudine dopo aver installato dipendenze di cui non sei sicuro. Allo stesso modo drop run --mount ~/dataset espone una cartella in sola lettura solo per quella sessione.
gVisor, il secondo muro alternativo al kernel
I namespace hanno un punto debole noto, cioè il programma isolato parla comunque direttamente con il kernel dell’host. Se nel kernel c’è una vulnerabilità sfruttabile, un processo dentro il recinto può in teoria usarla per uscirne. Per chi vuole chiudere anche questa porta, Drop supporta un secondo runtime basato su gVisor, il progetto di Google che fornisce una superficie compatibile con Linux in userspace, separando i processi dal kernel dell’host. Le chiamate di sistema del processo isolato non arrivano più al kernel vero, vengono intercettate e gestite da questo kernel in miniatura, che a sua volta ne usa un sottoinsieme molto ridotto verso l’host.
Per usarlo serve il binario runsc, che si installa con la procedura indicata dalla documentazione di gVisor.
(
set -e
ARCH=$(uname -m)
URL=https://storage.googleapis.com/gvisor/releases/release/latest/${ARCH}
wget ${URL}/runsc ${URL}/runsc.sha512
sha512sum -c runsc.sha512
rm -f runsc.sha512
chmod a+rx runsc
sudo mv runsc /usr/local/bin
)
Il runtime si sceglie per singola esecuzione oppure in modo permanente nel file di configurazione, e la scelta si può cambiare in qualunque momento sugli ambienti esistenti.
drop run --runtime gvisor npm install
runtime = "gvisor"
Il prezzo da pagare è la velocità delle chiamate di sistema, che con gVisor diventano più lente. Il rallentamento è contenuto con un agente che passa la maggior parte del tempo ad aspettare le risposte del modello, ma diventa più evidente durante operazioni che toccano migliaia di file, come l’installazione di un progetto JavaScript con centinaia di dipendenze. La soluzione più sensata è tenere il runtime nativo come predefinito e passare a gVisor per i lavori più rischiosi, come il primo npm install eseguito in un repository clonato da una fonte sconosciuta.
I limiti attuali di Drop
Drop è trasparente sui propri confini e i limiti dichiarati sono quattro.
- Solo terminale. I programmi con interfaccia grafica non partono con la configurazione predefinita, e il progetto sconsiglia di esporre il socket di X perché darebbe troppi privilegi.
- Dispositivi ridotti. Nel recinto ci sono solo pochi dispositivi di base, quindi niente audio e niente accesso diretto alla GPU.
- Niente setuid. I programmi che acquisiscono privilegi elevati all’avvio, come
sudo, non funzionano. - Niente namespace annidati. Podman e le applicazioni installate come Snap non girano, perché a loro volta hanno bisogno degli user namespace.
C’è poi da sapere che la cartella del progetto è scrivibile, quindi un pacchetto malevolo può modificare un Makefile, uno script in package.json, un file .envrc di direnv o le impostazioni dell’editor. Se poi lanci quei file fuori da Drop, il codice gira con il tuo account completo. La regola pratica è che ciò che è stato toccato nel recinto si esegue solo nel recinto.
Rispetto alle alternative, Drop si colloca in una nicchia precisa.
Bubblewrap e nsjail offrono gli stessi mattoni, ma vanno assemblati a mano con decine di opzioni. Firejail è pensato soprattutto per le applicazioni desktop e si installa con un binario setuid, che è esattamente il tipo di componente privilegiato che un sandbox dovrebbe evitare. I container Docker e i devcontainer offrono un isolamento efficace, ma richiedono in genere la costruzione o la configurazione di un’immagine, nella quale non sono automaticamente presenti tutti gli strumenti e le impostazioni dell’ambiente dell’utente. Resta il fatto che Drop è un progetto giovane e non ha ancora alle spalle anni di verifiche indipendenti come bubblewrap.
Il primo comando da chiudere nel recinto è npm install
Il grosso della sicurezza è garantito dal kernel con meccanismi collaudati da anni, mentre Drop li rende utilizzabili mantenendo disponibili i programmi e, quando configurato, parte dell’ambiente di lavoro dell’utente. Non deve essere considerato come unica difesa per chi maneggia segreti di produzione, e non sostituisce una macchina virtuale quando serve un isolamento completo.
Il consiglio è partire in piccolo: crea un ambiente per il progetto su cui lavori più spesso e prendi l’abitudine di eseguire lì dentro npm install, pip install e gli script scaricati da Internet. Con il tempo, il prefisso (drop) nel prompt diventerà familiare. A quel punto la domanda su cosa possa succedere durante un’installazione con npm avrà finalmente una risposta rassicurante: poco o nulla, perchè il danno potenziale sarà limitato ai file, ai servizi e alle risorse esposti all’ambiente.
