Omarchy, falla critica permette a qualsiasi processo di ottenere accesso root

Una configurazione pensata per rendere Docker più comodo da usare ha trasformato per oltre un anno il normale account desktop di Omarchy in qualcosa di molto vicino a un amministratore senza password. Il problema riguardava tutte le versioni precedenti alla 4.0.1: l’utente creato dalla distribuzione apparteneva automaticamente al gruppo Docker e poteva quindi impartire comandi a un daemon eseguito con privilegi root. Non servivano sudo, exploit del kernel o sofisticate tecniche di evasione; bastava che un processo della sessione utente riuscisse a comunicare con Docker.

Omarchy non è una distribuzione Linux generica: il progetto creato da David Heinemeier Hansson, noto anche come DHH, nasce sopra Arch Linux e punta soprattutto agli sviluppatori: editor, runtime, strumenti AI, Docker, GitHub CLI e numerose utilità arrivano già integrate o risultano facilmente installabili. Proprio su una workstation di sviluppo, però, una separazione debole tra utente normale e root può diventare particolarmente delicata: browser, IDE, script npm, agenti AI e dipendenze scaricate da Internet convivono spesso con chiavi SSH, token GitHub, credenziali cloud e accessi ai sistemi aziendali.

Perché appartenere al gruppo docker equivale quasi ad avere root

Sui sistemi Linux tradizionali, dockerd gira normalmente con privilegi root e riceve richieste attraverso il socket Unix /var/run/docker.sock.

Il client Docker usato dal terminale non crea direttamente container, namespace o mount: invia istruzioni al daemon, che svolge materialmente le operazioni con i propri privilegi.

Docker lo dice nella documentazione ufficiale: il gruppo docker concede privilegi di livello root. Il socket appartiene normalmente a root e gli utenti non autorizzati devono passare da sudo; aggiungere un account al gruppo docker permette invece al client di raggiungere direttamente il demone.

Da qui nasce il problema. Docker consente legittimamente di montare directory dell’host dentro un container. Se il daemon accetta una richiesta che monta la radice del filesystem Linux all’interno di un container eseguito come root, il processo nel container può leggere o modificare file che il normale utente desktop non potrebbe toccare.

L’isolamento del container non rappresenta quindi una barriera contro chi controlla già l’API Docker privilegiata: è lo stesso daemon root a predisporre il mount richiesto.

Il ricercatore ha dimostrato il problema su un’installazione Omarchy vulnerabile usando /etc/shadow, il file che contiene informazioni protette sugli account locali. Un normale cat /etc/shadow riceve correttamente “Permission denied“; chiedendo invece a Docker di montare / come directory del container, il file diventa leggibile attraverso il daemon dotato di privilegi elevati.

Non era necessario aprire un terminale o lanciare Docker volontariamente

Quando un processo nasce tramite fork, eredita gli identificativi utente e i gruppi supplementari del processo padre; tali informazioni restano normalmente valide anche dopo execve, quando il processo carica un nuovo programma. È il comportamento documentato nelle pagine del manuale Linux relative alle credenziali dei processi.

Di conseguenza, se la sessione grafica dell’utente parte con l’appartenenza al gruppo docker, quella facoltà non resta confinata alla shell. Il ricercatore ha esaminato l’albero dei processi sotto systemd --user e ha riscontrato il gruppo Docker su praticamente tutti i normali programmi della sessione.

Sulle versioni vulnerabili di Omarchy non serve insomma convincere l’utente a digitare un comando Docker. Un browser compromesso, un’estensione malevola, un IDE, uno script installato tramite un package manager, un tool scaricato da un repository o un agente AI capace di eseguire comandi potrebbe teoricamente raggiungere lo stesso socket.

Da quel momento la compromissione dell’account smetterebbe di essere confinata ai privilegi dell’utente e potrebbe estendersi all’intera macchina.

Omarchy 4.0.1 cambia completamente il comportamento predefinito

La documentazione attuale, aggiornata dopo la pubblicazione di Omarchy 4.0.1, spiega ora chiaramente che l’utente non appartiene al gruppo docker per impostazione predefinita. Docker si utilizza quindi tramite sudo, per esempio sudo docker ps o sudo docker compose up; le interfacce grafiche richiedono autorizzazione quando devono accedere al demone.

Chi volesse ripristinare l’impostazione precedente può farlo intervenendo su Setup, Security, Sudoless Docker. Omarchy mostra però un avviso e aggiunge l’utente al gruppo soltanto dopo una scelta esplicita. È un’impostazione molto più ragionevole: chi accetta il rischio può ancora evitare sudo, ma la distribuzione non assegna automaticamente quella capacità a ogni processo desktop.

Per verificare la configurazione basta aprire il terminale ed eseguire id oppure id -nG: se tra i gruppi associati all’account compare docker, l’utente conserva l’accesso al daemon Docker senza passare da sudo. Un controllo ulteriore si può effettuare con getent group docker, che mostra gli utenti esplicitamente associati al gruppo.