NixOS — уникальный дистрибутив Linux, который привлекает внимание своей декларативной моделью управления и системой управления пакетами Nix. Основной особенностью NixOS является возможность описывать весь системный конфиг в одном файле, что обеспечивает воспроизводимость, удобство и простоту управления. Механизм пакетного менеджера Nix, являющийся ядром системы, реализован таким образом, что каждый пакет и конфигурационный файл хранятся в едином Nix store — централизованном хранилище, требующем высокой степени контроля и безопасности. Однако уникальные особенности NixOS, помимо преимуществ, порождают определённые риски с точки зрения безопасности. Исследования, проведённые в 2025 году командой Snyk Security Labs, выявили ряд уязвимостей, позволяющих злоумышленникам использовать особенности реализации Nix для повышения привилегий с уровня обычного пользователя до root.
Эта цепочка эксплойтов стала значительным вызовом не только для NixOS, но и для родственных дистрибутивов, таких как Lix и Guix. Анализ уязвимостей начинается с понимания принципов работы Unix доменных сокетов — ключевого компонента, задействованного в эксплуатации уязвимостей. Отличаясь от TCP-сокетов, Unix доменные сокеты позволяют обмениваться не только данными, но и файловыми дескрипторами благодаря механизму SCM_RIGHTS. Такой подход создаёт возможность передачи открытых файловых дескрипторов между процессами, что имеет большое значение при работе с изолированными средами, например, песочницами. В системе Nix каждый сборочный процесс запускается в изолированной среде с ограниченными правами, используя специального пользователя nixbld1.
Файлы, создаваемые в процессе сборки, помещаются в Nix store, который смонтирован как только для чтения. При нормальной работе все файлы в хранилище становятся неизменяемыми, что предотвращает большинство атак, основанных на замене или модификации файлов. Но если сборка терпит неудачу, промежуточные файлы и каталоги остаются доступными с теми же правами, что и временная среда сборки. Исследователи обратили внимание, что возможна передача открытых файловых дескрипторов каталогов сборочного вывода из песочницы во внешний процесс через Unix доменный сокет. Таким образом, злоумышленник может получить доступ на запись к каталогу, который должен был бы стать неизменяемым и защищённым после завершения сборки.
Эта ситуация создаёт потенциально опасный сценарий, когда файлы в защищённом хранилище могут быть изменены или удалены. С использованием этой возможности была обнаружена классическая ошибка времени проверки и времени использования (TOCTOU) в реализации механизма очистки мусора в Nix store. Очистка мусора нужна для удаления устаревших или неиспользуемых пакетов из хранилища, но при рекурсивном удалении содержимого каталогов операция некорректно обрабатывала абсолютные пути. Вызов функции openat с абсолютным путём игнорировал дескриптор каталога, что позволяло в промежуток времени между проверкой и удалением файлов заменять компоненты пути на символические ссылки, перенаправляя удаление в произвольные системные каталоги. Эксплуатация этого бага позволяла злоумышленнику удалять содержимое любых каталогов в системе с правами root.
Хотя сама по себе безобидная возможность удалять файлы может показаться неопасной, она открывала путь для дальнейших атак – разрушая системные директории или каталоги с критически важными конфигурациями. В дальнейшем удалось выявить ещё более опасную уязвимость, связанную с некорректной обработкой файлов, созданных при сборке во временных каталогах в /tmp. Неверные тайминги операций создания, записи и изменения прав доступа (chown) давали возможность заменять создаваемые файлы на символические ссылки к произвольным целям. В отличие от предыдущих ошибок, эта дыра позволяла менять владельца и группу произвольных файлов в системе с правами root, обеспечивая контроль над ними. Соединение всех этих уязвимостей помогло построить сложную цепочку эксплуатации.
Сначала получался доступ к изменению файлов внутри Nix store, затем реализовывалась атака TOCTOU для произвольного удаления, после чего на основе начального контроля строилась атака для изменения прав на системные каталоги, например, на /etc/pam.d. В результате можно было подменять критические параметры аутентификации, позволяя любому пользователю системы получить root-доступ без ввода пароля. Чтобы реализовать описанную атаку, использовались несколько элементов. Во-первых, технология передачи файловых дескрипторов через Unix доменные сокеты позволяла взаимодействовать между изолированным пользователем сборки и внешними процессами.
Во-вторых, грамотно организованный ввод-вывод с большим числом временных файлов и директорий создавал окна времени, необходимые для проведения вмешательства. В-третьих, манипуляции с символическими ссылками и временными каталогами обеспечивали обход ограничений, закладываемых системой безопасности. Реакция разработчиков NixOS и родственных проектов была быстрой и комплексной. Появились патчи, обеспечивающие корректное использование относительных путей при работе с файловыми дескрипторами, устранение возможности передачи дескрипторов в рискованных моментах, а также механизмы для безопасной передачи данных между песочницей и внешним миром по безопасным каналам с учётом сетевой изоляции. Кроме того, они внедрили использование новых технологий сетевой изоляции, таких как pasta networking, позволяющей обеспечить доступ к интернету внутри песочницы без пробелов в безопасности.
Опыт данной уязвимости подчёркивает важность комбинированного подхода к безопасности — нельзя полагаться только на один механизм защиты. Общая безопасность системы зависит от корректной реализации каждой её части, особенно в системах с комплексной архитектурой и возможностями декларативной конфигурации. В частности, даже несовершенные ошибки, которые кажутся мелкими, способны накапливаться, образуя exploitable цепочки. В итоге, изучение NixOS продемонстрировало, как декларативное управление системой идёт рука об руку с вызовами в области безопасности. Уникальные технические решения, применённые в дистрибутиве, требуют внимательного анализа и постоянного контроля.
Многоуровневые механизмы песочниц, файловые дескрипторы и операции с файловой системой — всё это потенциальные точки риска, если не проработаны должным образом. Для пользователей и администраторов NixOS ключевым выводом становится необходимость своевременного обновления систем и внедрения рекомендованных патчей безопасности. Также важно отслеживать новейшие исследования в области уязвимостей и уделять внимание конфигурационным параметрам, касающимся работы песочниц и доступа к системным ресурсам. Экосистема Nix продолжит развиваться, и безопасность останется в числе приоритетных задач. Опыт, полученный благодаря тщательному аудиту и исследованию, предоставленному лабораторией Snyk, стимулирует проекты уделять больше внимания выявлению многокомпонентных уязвимостей и их устранению в самых ранних стадиях.
Это поможет сохранить репутацию NixOS как мощного и надежного инструмента для управления современными инфраструктурами.
