Omarchy : chaque programme pouvait devenir root

Ce qui se passe

Omarchy, la distribution Arch mise en avant par DHH, plaçait son compte utilisateur par défaut dans le groupe docker. L'intention est banale — pouvoir taper docker run sans sudo — mais sur Arch le démon Docker s'exécute en root et écoute sur /var/run/docker.sock. Appartenir à ce groupe, c'est pouvoir parler à ce démon, donc lui demander de faire en root ce qu'on veut.

Le rapporteur a suivi la procédure de divulgation du projet avant de publier. La configuration a été corrigée : toutes les versions antérieures à 4.0.1 sont concernées, y compris la dernière image 3.x testée, la 3.8.4.

La démonstration tient en deux commandes. La première échoue :

cat /etc/shadow
# cat: /etc/shadow: Permission denied

La seconde réussit, sans mot de passe ni élévation visible :

docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow

L'utilisateur n'a rien lu lui-même. Il a demandé à un démon root de le faire.

Pourquoi ça compte

La portée est ce qui rend l'affaire sérieuse. Sous Linux, les groupes supplémentaires sont hérités par les processus fils. En parcourant l'arbre de processus sous l'instance systemd --user, le rapporteur a retrouvé l'appartenance au groupe docker sur pratiquement tout ce qui tourne dans une session de bureau : navigateur web, éditeur et IDE, scripts npm, agents de code et leurs harnais, outils de développement divers, tâches de fond.

Autrement dit, tout endroit où du code non fiable peut s'exécuter devenait un chemin vers root. La compromission d'une application ordinaire — une extension de navigateur, un paquet npm piégé — se transformait immédiatement en compromission complète de la machine.

Deuxième point, plus structurel : le réglage était appliqué par défaut, pas proposé. Un utilisateur qui ne se sert jamais de Docker en héritait quand même, sans que le compromis lui soit expliqué. La documentation du projet évoquait bien le groupe, en indiquant qu'elle permettait de lancer Docker « as the normal user and not as root » — une formulation dont un lecteur peut raisonnablement conclure à un mode rootless, alors que l'implication de sécurité est exactement inverse.

Ce qu'il faut faire

1. Passer en 4.0.1 ou plus récent.
2. Vérifier ses groupes avec id : si docker y figure encore sur un compte restauré depuis une ancienne installation, le retirer avec gpasswd -d $USER docker, puis rouvrir la session.
3. Si l'on veut des conteneurs sans concéder root, regarder Podman : il est sans démon, les conteneurs tournent comme processus fils de l'utilisateur dans leurs propres espaces de noms.

La chronologie des commits est publique : groupe docker ajouté le 1er juin 2025 (25799ee), désactivé le lendemain (c5ee230), réactivé le 17 juin 2025 (fdd2aaf), puis retiré de la configuration par défaut le 24 août 2026 (b5ded31).

Source : 0xcc.io — Omarchy: Any User Process Can Escalate to Root