В современном мире информационной безопасности вопросы защиты систем становятся все более актуальными. Особенно это касается инструментов управления пакетами и сборок, таких как Lix — независимый вариант пакетного менеджера Nix. Недавно командой безопасности Lix было объявлено о наличии пяти серьезных уязвимостей, которые получили соответствующие CVE-номера. Эти проблемы способны привести к локальному повышению привилегий и другим нежелательным последствиям, что вынудило разработчиков приложить максимум усилий для их оперативного устранения и выпустить важные обновления. Весной 2025 года произошла шквала активных действий по выявлению, устранению и тестированию багов, способных ставить под угрозу безопасность пользователей.
Lix является сложным комплексом программ, работающих с моделью сборок и управлением пакетами, где большая часть процессов выполняется под ограниченными пользователями (nixbld*), а ключевой сервис — nix-daemon — работает с повышенными привилегиями от имени root. Эта архитектура изначально призвана исключить риск несанкционированного доступа, однако детали реализации рядовых операций с файлами и временными каталогами оставляли пространство для потенциальных атак. Особенно уязвимыми оказались методы обработки временных директорий и использования UNIX domain sockets в Linux. Основной вектор атаки связан с так называемым time-of-check vs. time-of-use (TOCTOU) — проблемой, когда между моментом проверки состояния файловой системы и их непосредственным использованием возникает возможность вмешательства злоумышленника.
В Lix это проявлялось в том, что многие операции со ссылками на файлы осуществлялись по строковым путям вместо использования файловых дескрипторов, что позволяло перехватывать и манипулировать объектами файловой системы. Эти «окна» использования пути как идентификатора файла позволяли заменить директории или файлы между проверкой и вызовом, создавая риск повышения привилегий внутри системы. Отдельным критическим дефектом стала ошибка в давно существующей функции рекурсивного удаления. Изначально функция должна была безопасно удалять каталоги, используя дескрипторы директории для предотвращения замены каталогов во время удаления. Однако из-за неверного обращения с переменными и смешивания абсолютных и относительных путей, вместо корректных вызовов unlinkat с дескрипторами, вызывалась команда с длинным абсолютным путем, что породило уязвимость – злоумышленник мог заменить tmp-дериктории на свои собственные, что приводило к удалению и подмене системных данных.
Очевидно, что подобные баги нельзя оставлять без контроля. В ответ разработчики кардинально пересмотрели логику работы с временными файлами и каталогами. Основным исправлением стало активное повсеместное использование файловых дескрипторов при работе с каталогами и файлами, что существенно снижает риск подмены объектов между проверкой и использованием. Кроме того, особое внимание уделили проверкам корректности поступающих дескрипторов во время сборок, чтобы гарантировать, что задействованные ресурсы действительно соответствуют ожидаемым. Еще одной важной мерой стала смена места проведения сборок.
Если раньше сборки происходили в общедоступных и общезаписываемых временных каталогах вроде /tmp, что облегчало атаки, то теперь сборочные директории размещаются в специально защищенном пространстве — /nix/var/nix/builds. Этот каталог находится под полным контролем nix-daemon и недоступен для посторонних пользователей, что значительно повышает безопасность и исключает возможность подмены каталогов. Однако с этой сменой связаны и некоторые особенности. Ранее многие пользователи предпочитали /tmp как tmpfs, то есть папку в памяти RAM, для ускорения сборок и снижения износа дисков. Перемещение в /nix/var/nix/builds, который часто находится на диске, требует пересмотра подходов к монтажу файловых систем, чтобы сохранить производительность сборок.
Также стоит отметить нововведение в области изоляции сетевого стека во время сборок. Linux позволяет создавать изолированные сетевые пространственные имена (network namespaces), в которых процессы видят собственный набор сетевых интерфейсов и сокетов. Прежде проблема возникала с фиксированными выводами сборок (fixed-output derivations), которые имели доступ к сети хоста и могли использовать абстрактные UNIX domain сокеты, доступные в общем сетевом пространстве. Это давало возможность обмениваться файловыми дескрипторами и обходить ограничения изоляции. Теперь для таких сборок опционально применяется инструмент Pasta, создающий на время сборки отдельный сетевой namespace с маршрутизацией трафика через пользовательский процесс.
В результате, фиксированные сборки остаются изолированными от хоста и друг от друга, что снижает вероятность межпроцессных атак. Эти меры дополняются защитой через модули безопасности Linux (LSM), хотя их внедрение сложное и пока находится в процессе развития. Была предпринята попытка запретить использование абстрактных UNIX сокетов на уровне LSM, однако это вызывает технические трудности из-за необходимости точечной фильтрации по пользователям и cgroups. Разработчики рекомендуют рассматривать такой запрет как функцию уровня системных сервисов, например systemd, с последующей интеграцией с cgroups для эффективной изоляции. Стоит уточнить, что подобные меры касаются преимущественно Linux-сред.
В macOS, где изоляция сетей и файловых систем работает иначе, действуют свои подходы. В частности, sandbox-механизмы macOS по умолчанию изолируют сборки по сети, но не обеспечивают файловую изоляцию так, как это реализовано на Linux. При специальных настройках («sandbox=relaxed» или отключении песочницы) границы изоляции значительно снижаются, что требует дополнительной бдительности. Повышенное внимание к безопасности и исправлению выявленных багов стало результатом активной работы команды Lix совместно с внешними исследователями, в том числе Rory McNamara из Snyk Security Labs, и открытого сотрудничества сообщества. Были выпущены обновления Lix 2.
91, 2.92 и 2.93, которые закрывают известные уязвимости. Разработчики настоятельно советуют всем пользователям немедленно перейти на эти новые версии и отказаться от использования устаревших 2.90 версий из-за высокой сложности их поддержки и невозможности легкой портировки исправлений.
Понимание возможных функциональных изменений также очень важно. В частности, использование Pasta может вызвать неожиданное поведение у некоторых сборок, особенно тех, которые задействуют сложные сетевые протоколы или специфичные функции TCP/UDP. Например, сборки, использующие fetchBittorrent или нестандартные UDP протоколы, могут столкнуться с проблемами, а поддержка протоколов SCTP вовсе отсутствует. В подобных случаях рекомендуется сообщать о багах, а также временно выключать Pasta, если стабильность важнее безопасности. Для пользователей NixOS обновление часто происходит через nixpkgs и nixos-channel, и может потребовать переустановки пакетов и пересборки Lix.
Для тех, кто не использует NixOS, доступны бинарные обновления через встроенный механизм nix upgrade-nix или вручную посредством патчей. В случае применения сторонних менеджеров пакетов или дистрибутивов рекомендуется обращаться к своей команде безопасности для получения обновлений или инструкций. Итогом текущих усилий стало значительное укрепление безопасности Lix, снижение риска локального повышения привилегий и правил безопасности при выполнении сборок. Тем не менее пользователям важно сохранять постоянную внимательность, своевременно обновлять программное обеспечение и принимать во внимание рекомендации по конфигурации и изоляции. Безопасность — это комплексный процесс, требующий постоянного совершенствования и адаптации к новым угрозам.
Подводя итог, исправления пяти CVE-уязвимостей в Lix стали результатом кропотливой работы сообщества, направленной на устранение ключевых проблем с безопасностью, изменением архитектуры работы с временными каталогами и файловыми дескрипторами, а также внедрением новых механизмов изоляции сетевого пространства. Благодаря этим мерам Lix сегодня предлагает повышенную защиту для пользователей и демонстрирует пример ответственного подхода к поддержке безопасности в экосистеме open source.
