Уязвимости в Nix и Lix, позволяющие поднять привилегии в системе

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

Навернули костылей. А могли бы просто озадачить нейросеть на расте переговнокодить всё. Зря память дорожала штоле.

Не понял при чём тут конкретно nix. Уязвимость с переполнением стека в аллоцированную память была архитектурная, проявилась особенно явно в Xorg несколько лет назад, тогда ещё Линус лично внёс какие-то фиксы в ядро чтобы такого не происходило. Как nix смог их обойти?

Хмм. Мне казалось что года 2-3 назад читал это на лоре и оно было актуальным.

Но нашлось только вот что из 2010 года https://lwn.net/Articles/400746/

Ну читал то я точно недавно, но возможно значит это какая-то старая тема была.

РЕШЕТО!

Если у кого-то был вопрос, почему реализовать пакетный менеджер в виде демона, запущенного от рута, к которому подключаются непривилигированные пользователи — так себе идея; то вот и подъехал ответ.

А вы ещё спрашивал зачем нужен Guix.

А чем это принципиально отличается от пакетного менеджера, который пользователям приходится запускать от root’а?

Навернули костылей. А могли бы просто озадачить нейросеть на расте переговнокодить всё. Зря память дорожала штоле.

Lix is designed for evolution of its codebase. Lix already uses the more modern meson build system, which improves developer usability and decreases build times. Plans include a gradual, piecewise introduction of the memory-safe Rust programming language – to both supplement and replace sections of the current C++ codebase.

Хорошо что этим пользовались всего три с половиной школьника :)

ебята, переходим на https://guix.gnu.org/

ебята, переходим на https://guix.gnu.org/

Так я уже.

Это потому что на Rust не написано.

выполняется под пользователем root

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

На кой хрен собирать под root? Они прям до такой степени не смогли в архитектуру ОС?

Уязвимости в Nix и Lix

Прям Биба и Боба :-P

А чем это принципиально отличается от пакетного менеджера, который пользователям приходится запускать от root’а?

Тем, что в случае с пакетным менеджером, просто запускаемым от root’а нет никакого демона, нет ситуации, когда именно такая уязвимость может появиться, когда в случайный момент времени запущенная от любого юзера программа (в том числе от того, который не имеет прав на запуск чего-либо через sudo — это может быть вообще какой-то технический «пользователь» с очерь ограниченными правами) может повысить привилегии благодаря постоянно запущенному демону.

У нас что, неделя уязвимостей?

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

Ну вот например systemd - постоянно запущенный демон. Кто то гарантирует что попытка потрогать юнит с именем длинее 4Гб (для примера) не приведёт к выполнению кода с правами рута?

Естественно могут. И свято, что твой код безупречен и не имеет багов приводящих к уязвимости — плохая стратегия. Но если нет постоянно запущенного от рута демона, то использование этих уязвимостей на практике сильно затрудняется и начинает требовать более специфичных условий. В случае с обычным пакетным менеджером злоумышленику придётся сперва как-то поднять привилегии (например через уязвимость в sudo), чтобы запустить этот самый ПМ от рута, и только потом уже делать свои деструктивные действия. А здесь возникает новая поверхность для атаки.

Ну вот например systemd - постоянно запущенный демон. Кто то гарантирует что попытка потрогать юнит с именем длинее 4Гб (для примера) не приведёт к выполнению кода с правами рута?

Очень правильный ход мыслей. Никто. systemd — это вообще главная проблема линукса, начиная с его повсеместного внедрения.

Переусложнение компонентов ведёт к большей поверхности для атаки.

Lix is designed for evolution of its codebase. Lix already uses the more modern meson build system, which improves developer usability and decreases build times. Plans include a gradual, piecewise introduction of the memory-safe Rust programming language – to both supplement and replace sections of the current C++ codebase.

Хорошая отмазка, возьму на вооружение: «Ребят, код не говно, он просто готов к эволюции».

запущенная от любого юзера программа

При необходимости можно задать allowed-users = root @wheel в nix.conf, что позволит подключаться к nix-daemon только руту и пользователям из группы wheel.

Астрологи объявляют неделю решета. CVE всех проектов возросло.

А чем это принципиально отличается от пакетного менеджера, который пользователям приходится запускать от root’а?

если пользователь может запустить пакетный менеджер через sudo, значит ему права такие дали.

В случае же данной уязвимости

Проблема может быть эксплуатирована любым пользователем, способным устанавливать соединения к nix-daemon. По умолчанию все пользователи имеют такую возможность

Прав на sudo может и не быть , а рута всё равно сможешь получить.

Можно. И нафига тогда вообще этот демон?

И да, поверхность для атаки всё ещё выше. Внезапно может открыться, что если имя юзера содержит нынешнюю фазу луны, пять символов процента подряд, и состоит из более чем 4096 символов, то проверка ломается, а доступ таки получается. Я жёстко утрирую, конечно, но суть ясна.

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

Пожалуй всё это так, но ведь надо же как то дать обычным юзерам права на установку обновлений. Опционально там, или конкретно в этом дистрибутиве. И сама эта возможность - воле для уязвимостей.

Если конкретно обновлений, а не установки новых пакетов, то можно дать права на sudo конкретной команды. Без возможности установки чего-то или передачи ещё каких-то аргументов. Да, в этом случае тоже есть некоторая вероятность наткнуться на уязвимость. Но она намного, прям очень намного ниже, меньше поверхность для атаки.

Да и даже если с установкой новых пакетов — ты дашь эти права конкретным юзерам. И только они смогут вообще в принципе запустить менеджер пакетов. У тебя не будет ситуации, что постоянно висит демон, запущенный от рута, к которому может постучаться вообще любой юзер, имеющийся в системе. Да, выше сказали, что список таких пользователей можно ограничить — но это ограничение внутри демона всё равно, уязвимость гипотетически может срабатывать до проверки на вхождение юзера в список.

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

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

«постучаться» до демона тоже можно по разному. Например через одноклеточный текстовый api, способный передавать 4 команды и имя пакета.

Ну в принципе да. Но тем не менее, нет демона там, где он не требуется — нет проблем.

В данном случае стоит, потому что простое не умеет почти ничего, кроме как просто ставить и удалять пакеты. Лично мне не нужен очередной простой как палка pacman, xbps или apk.

Кстати, ответ от Guix’а тоже давно уже подъехал.

Daemon Running Without Privileges

The second and preferred option is to run guix-daemon as an unprivileged user. It has the advantage of reducing the harm that can be done should a build process manage to exploit a vulnerability in the daemon.

systemd — это вообще главная проблема линукса

Главная проблема линукса это необучаемые идиоты, возомнившие себя сисадминами. С остальными проблемами systemd справляется на отлично.

начиная с его повсеместного внедрения

Это вообще лучшее что случалось c GNU/Linux в этом веке.

Переусложнение компонентов ведёт к большей поверхности для атаки.

Верно подмечено - это один из плюсов внедрения systemd: высокая модульность и продуманные интерфейсы вместе с грамотными механизмами защиты резко сокращают поверхность атаки.