Читал тут исходники pulse audio. Осознал, что Поттеринг всю жизнь пишет одну и ту же программу - граф обработки каких-нить событий в realtime, и обязательно чтобы граф связывался в runtime, и без проверок на то, что этот граф может выполниться в реальной жизни. Ну не дает покоя человеку эта идея.

Бывает, чо. Некоторые вот уже 5-ую систему сборки пишут.

———
#gold, #security

Сначала небольшая вводная, для тех, кто с нами недавно.

Mix - это пакетный менеджер для linux/macos, и дистрибутив Linux на основе.

Я очень хочу, чтобы пакетным менеджером пользовалось как можно больше народу(не прямо сейчас, а вообще), потому что 1 человек потянет 500 пакетов(у меня сейчас 300), а больше уже нужно больше людей.

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

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

Поэтому я предполагаю, что у меня будет несколько "пресетов" - наборов пакетов, которые формируюут законченную идею(вид линковки + libc + DE + whatever).

Далее, когда я говорю, что "у меня в Mix вот так-то", я имею в виду вот этот вот пресет - https://github.com/pg83/mix/blob/main/pkgs/set/system/0/mix.sh, или System/0 #system0. Все, что я делаю в нем, может и не относиться к потенциальному Mix на #systemd + gnome.

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

Так, вводная закончилась. Далее про то, как будет устроен System/0(а точнее, про один из аспектов устройства).

Мне очень хочется, чтобы пакетный менеджер не работал от root, и чтобы в нем не было postinstall скриптов. А точнее, я хочу, чтобы пакет можно было установить, распаковав папку с его содержимым, и все. Это здорово облегчает реализацию, и упрощает модель безопасности. Скажем, как в Android.

Я решил почти все проблемы, связанные с этим:

* заведение пользователей/групп
* резолвер
* динамическая настройка сети

Да даже попакетные настройки ядра.

Но вот одна проблема оставалась для меня сложной. Как эскалировать привилегии? Да, sudo. Если пакетный менеджер не работает от root, нет postinstall скриптов, то как получить #suid бинарник в системе?

До недавнего времени я решал эту задачу довольно криво - фоновый процесс, который проставлял setuid бит некторым бинарям.

На днях придумал элегантное решение, и спешу им поделиться.

На хосте запущен(скажем, через socket activation) ssh демон, от рута. И sudo - это простой скрипт, который делает ssh root@localhost. ssh поднят на unix domain socket, чтобы не светить в сеть. Базово эта схема уже работает.

Чем больше думаю, тем больше мне эта схема нравится.

* Эскалация привилегий в ssh, я думаю, отлажена даже лучше, чем в sudo. Потому что так мы привилегии эскалируем IMHO чаще.

* Вход не по паролю, а по ключу, 1 на пользователя, а не одному на host.

* Парольный/беспарольный вход остается на стороне пользователя(пароль на приватной части ключа), без fragile вмешательства в /etc.

Схема работает очень годно - у меня нет ни одного #suid бинаря.

#stal/ix #security #ROP

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

Возьмем, например, https://en.wikipedia.org/wiki/Return-oriented_programming

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

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

func1:
...
A
B
ret

func2:
...
C
D
ret

Вот, можно так аугментировать call stack, что будет выполнено:

A
B
ret
C
D
ret
...

Тут, конечно, вдумчивый читатель спросит - а где взять эти самые кусочки? Чаще всего их можно взять в хорошо известных и стабильных последовательностях кода, типа libc.so

Количество реюзабельных кусочков пропорционально общему объему кода программы.

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

А, значит, "более безопасна"!

#security #CVE

Меня тут спрашивают, почему я не пишу про всякие интересные уязвимости в CPU, типа

https://www.opennet.ru/opennews/art.shtml?num=59571
https://comsec.ethz.ch/research/microarch/inception/

Я не знаю.

Это было интересно в первый раз (а все помнят название первой уязвимости такого класса? Я вот уже забыл).

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

Я бы тут поспекулировал, что это вообще свойствено уязвимостям.

Когда их сложно найти, и легко починить, то почет и уважение тем, кто их ищет, почет и уважение тем, кто их фиксит, все довольны, все получили свою 5+, и всем пофиг, что ущерб не нанесен, потому что in the wild оно не эксплуатировалось.

А вот когда починить реально дорого, прямо очень дорого, то люди ВНЕЗАПНО вспоминают, что умеют считать деньги, и просто игнорируют всю эту шелуху и весь этот абсурдный театр безопасности.

#security

https://github.com/CuBeRJAN/nix-problems

А вот, например, неплохой список проблем в Nix. С удовольствием читаю такое, потому что, в каких-то аспектах Nix мой прямой конкурент, и хочется сделать лучше.

С некоторыми тезисами оттуда я совершенно не согласен, например, жалоба на то, что коммиты в nixpkgs не подписаны. И ссылка на обсуждение https://github.com/NixOS/rfcs/pull/100.

Я не понимаю необходимость подписи коммитов. Мне не нужно знать кто мне прислал коммит с фиксом сборки пакета. Мне его нужно прочитать, запустить на него CI, после чего я принмаю на себя грех ответственность, и публикую его у себя.

То есть, мой результат - это git sha, который является комбинацией моего предыдущего дерева, и нового changeset.

Если вы получили один и тот же git sha с github, и с моего независимо работающего сайта, где я публикую свежие релизы, то чего же желать еще?

https://www.opennet.ru/opennews/art.shtml?num=63464

"В пакетных менеджерах GNU Guix, Nix и Lix выявлены уязвимиости (Nix, Guix, Lix), позволяющие выполнить код с правами пользователей, под которыми запускаются сборочные задания (например, nixbld* в Nix/Lix), что может использоваться для записи своих данных в сборочное окружение и внесения изменений в сборочный процесс. Проблемы присутствуют в фоновых процессах guix-daemon и nix-daemon, применяемых для организации доступа непривилегированных пользователей к сборочным операциям"

Я, когда дизайнил это место в #IX (https://t.iss.one/itpgchannel/179, тогда это еще называлось #mix, до ребрендинга, #security), смотрел на то, как это сделано в nix и guix. Мне это место с демоном показалось довольно тонким, и я решил, что имеющейся у меня изоляции не хватит на то, чтобы гарантировать безопасность.

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

Фактически, любой вызов ix build у меня содержит вызов su -s /bin/sh ix -- executor ..., для непосредственного применения построенного графа к системе (в других терминах, конечно, потому что у меня нет классических способов поменять пользователя, #suid).

Натурально, можешь стать пользователем ix - можешь менять систему.

Поэтому такой проблемы у меня нет, и быть не может.