Уязвимость конфигурации Docker по умолчанию в дистрибутиве Omarchy приводила к тому, что практически любая программа, запущенная в пользовательской десктоп-сессии, могла получить root-доступ без пароля, sudo или запроса привилегий.

Тем, кто пользуется Omarchy, важно запомнить одно: нужно обновиться до версии 4.0.1.

Об уязвимости сообщили разработчикам через процесс ответственного раскрытия информации. Конфигурацию уже исправили, поэтому детали публикуются сейчас — чтобы объяснить суть проблемы и напомнить пользователям об обновлении систем.

Суть проблемы

Omarchy по умолчанию добавляла пользователя в группу Linux docker.

Это позволяет выполнять такие команды:

docker run ...

без ввода sudo.

На Arch демон Docker работает от имени root и слушает сокет:

/var/run/docker.sock

Участники группы docker могут обмениваться данными с этим сокетом. Сама документация Docker прямо предупреждает, что членство в группе docker фактически даёт пользователю root-привилегии.

Процесс с доступом к сокету Docker может попросить работающий от root демон запустить контейнер от root, смонтировать в него произвольные части файловой системы хоста, работать с этими файлами от имени root и выполнять код с правами root.

На затронутых системах Omarchy это означает, что пользователь по умолчанию и все процессы, запущенные в его сессии, фактически имеют доступ к root.

Демонстрация уязвимости

На свежей уязвимой установке Omarchy попытка прочитать /etc/shadow завершается ожидаемо:

$ cat /etc/shadow
cat: /etc/shadow: Permission denied

Проверка групп пользователя:

$ id
uid=1000(tester) gid=1000(tester) groups=1000(tester),967(docker),992(input),998(wheel)

Теперь можно прочитать защищённый файл, используя Docker, работающий от root:

$ docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow
root:$6$...
bin:!*:...
daemon:!*:...
...

Команда запускается обычным пользовательским процессом, но фактический доступ к файловой системе выполняет демон, работающий от root.

Масштаб проблемы

Дополнительные группы Linux наследуются дочерними процессами, поэтому проблема затрагивает всю пользовательскую сессию целиком.

Проход по дереву процессов ниже пользовательского экземпляра systemd --user показал, что группа docker присутствует практически у каждого обычного процесса в сессии.

Это значит, что почти любой процесс, в котором могло бы выполниться недоверенное окружение, мог получить root, включая:

  • AI-агенты для кодинга и их обвязки
  • веб-браузеры
  • редакторы и IDE
  • npm-скрипты
  • случайные инструменты разработки
  • фоновые процессы

Иными словами, компрометация обычного пользовательского приложения могла мгновенно превратиться в полную компрометацию машины.

Настройки безопасности по умолчанию

Есть ещё один важный момент в этой конфигурации: она была включена по умолчанию, а не по явному согласию пользователя. Использовать Docker вовсе не обязательно — но компромисс в области безопасности был сделан за пользователя, применён к учётной записи по умолчанию, и никак не объяснён.

Настройки безопасности по умолчанию важны именно потому, что многие пользователи разумно полагают: операционная система по умолчанию безопасна и предупредит их или запросит подтверждение перед применением менее безопасных настроек.

Вводящая в заблуждение документация

В документации по инструментам разработки Omarchy упоминала группу docker:

Omarchy устанавливает всё необходимое для комфортной работы с [docker]. Включая […] изменения групп пользователя, нужные для того, чтобы запускать Docker от обычного пользователя, а не от root.

Смысл этой формулировки с точки зрения безопасности почти противоположен тому, что обычно подразумевает читатель под фразой «не от root». Прочитав такое описание, пользователь мог разумно решить, что Omarchy настроила Docker в некоем rootless-режиме. На деле это было не так.

Затронутые версии

Проблема затрагивает версии до 4.0.1. Тестирование на последнем ISO ветки 3.x (3.8.4) также подтвердило уязвимость.

Хронология

Хронология коммитов — от появления проблемы до её устранения:

Более широкий контекст

На фоне того, как ИИ всё чаще становится причиной серьёзных CVE в базовой инфраструктуре, вопросы безопасности должны быть в приоритете у всех разработчиков, а тем более у авторов дистрибутивов, ориентированных на разработчиков. В последнее время появляется бесчисленное множество сообщений о компрометации машин разработчиков, чей доступ затем используется для заражения цепочки поставок ПО или эксплуатации продакшн-систем. Разработчики — привлекательная цель именно из-за уровня доступа, который им обычно предоставляется. Машины разработчиков часто отключают защитные механизмы ради удобства, хранят учётные данные в текстовых dotfile-ах и накапливают доступ к системам. Это должно измениться.

Скорее всего, добавление группы docker было простым недосмотром со стороны DHH, не до конца осознавшего последствия. Ни один дистрибутив не принимает идеальных решений в вопросах безопасности. Скорость реакции на сообщение об этой проблеме впечатлила — это хороший знак.

Тем не менее это не первый случай столкновения с проблемами безопасности в Omarchy, и в целом доверия к текущему процессу принятия решений, обеспечивающему тот уровень безопасности, который ожидается от дистрибутива, пока недостаточно. Хочется верить, что ситуация изменится, поскольку в Omarchy есть немало достоинств.

Podman

Пользователям Docker в Linux, не желающим предоставлять root-доступ (даже через sudo) для запуска контейнеров, стоит попробовать Podman. Podman работает без демона: контейнеры запускаются как обычные дочерние процессы в собственных пользовательских пространствах имён и не требуют root-доступа в каком-либо виде. Podman используется уже много месяцев и полностью заменил все рабочие процессы на основе Docker. Попробовать точно стоит.

Источники