Читал тут исходники 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 бинаря.

Я тут себе собирал свое личное ядро для System/0 #system0. Это оказалось очень сложно, и заняло 4 бессонных ночи(+ целиком прошлое воскресенье).

Ну, то есть, собрать-то легко, а вот сделать так, чтобы оно заработало, очень сложно.

* Первое ядро ничего не писало на экран, и просто мигало капсом(это типа такой kernel panic). https://en.wikipedia.org/wiki/Kernel_panic#Linux. К счастью, от Gentoo я знал историю про то, что ядро себя так ведет с amdgpu, если не может загрузить firmware. Незачет номер раз - в такой ситуации нормальные люди откатывались бы на efi framebuffer, и показывали хотя бы сообщение об ошибке. Видимо, реализовать приоритет драйверов - это очень сложно.

* Загрузка firmware. Ядро напрочь отказалось загружать firmware с файловой системы, а до firmwared дело просто не доходило. Я так понимаю, некоторые штуки надо загружать или только из initrd,или прямо вкомпилять внутрь ядра. Я пока вкомпилял внутрь, причем вообще всю фирмварь для amdgpu, так как я уже писал, что нормального способа узнать, что загружено - не существует. - несколько часов.

* Для интелевых карточек в репе лежит примерно 20 разных фирмварей. Если дать ядру возможность выбора, то драйвер загружает НЕ ТУ фирмварь(оно при попытке поднять интерфейс срет в dmesg). То есть, фирмварь пришлось заблеклистить. На минуточку, драйвер от Intel, загружает фирмварь от Intel, подписанный Intel, для интеловой же карты, и ошибается. - несколько часов.

* Дальше началось самое интересное. Не работал мой тачпад в Sway. Последовательный bisect проблем показал, что ядро не видит тачпад, и не создает для него /dev/input/чегототам. Суммарно на решение этой проблемы ушло часов 20, за которые я успел по настоящему подебажить ядро. Я узнал, что такое шина i2c, hid, как они сопрягаются, и кучу прочего бесполезного барахла. А теперь придется и вам.

Итак, мое текущее понимание устройства ядра(это все довольно поверхностно, физически устроено еще сложнее *):

* Ядро - это такой большой std::map<void*, void*> M, как Spring :))
* Все подсистемы могут туда что-то положить, и зарегистрировать.
* Все подсистемы там могут что-то поискать, и что-то дернуть.

Какие отсюда интересные следствия?

* Если ты забыл что-то вкомпилять в ядро, то посреди цепочки регистрации что-то потеряется, и твое устройство не будет найдено.
* В модулях ядра стоят неполные зависимости. Что это значит? Это значит, что загрузятся не все нужные подсистемы, и мы возвращаемся в пункт 1.
* Зависимость от порядка регистрации. Если его не соблюсти, то в момент регистрации драйвера могут быть зареганы не все нужные подсистемы(пункт 2), и возвращаемся в пункт 1.

В моем конкретном случае я забыл** вкомпилять драйвер для gpio pins. Не спрашивайте что это такое, я к ядру подхожу с чисто практической точки зрения - "проходит или не проходит сигнал", а что там - мне глубоко пофиг.

Поэтому шина i2c видела мое устройство, но сигнал не доходил до HID драйвера, и устройство не могло зарегаться.

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

В конце-концов я нашел модуль про gpio pins, увидел, что его нет в зависимостях ни у i2c, ни у hid, и все стало понятно.

Кстати, собрать ядро со всеми драйверами built in невозможно(будет падать, или бесконечно висеть в probe девайсов), потому что это какое-то безумие - probe у некоторых драйверов работает лишь по факту их включения в ядро, что потенциально ломает систему, если нужного девайса нет. У меня это выражалось в том, что попытка загрузить какой-то левый драйвер для i2c контроллера ломало драйвер для настоящего i2c контроллера.

Почему нельзя вкомпилять в ядро на правах модуля(типа, звать probe только тогда, когда явно попросили init этого драйвера) - непонятно.

Короче, ядро у меня уже свое, но пока не до конца пригодно для всех.

Я думаю, вы уже поняли, что #system0 - это "моя прелллесть" :)

В ней я, по мере сил, намерен исправить разные проблемы, с которыми я сталкивался по мере взаимодействия с Linux/Unix.

Одна из таких проблем - это свойство Unix по наследованию init-ом процессов, у которых умер родитель. Я считаю, что это треш, угар, и содомия(и одна из причин появления cgroups, кстати). Мне приятно видеть completely supervised tree, если вы понимаете, о чем я. Это удобно и для понимания, и для отладки. Долгоживущие процессы надо запускать через команду spawn сессионного супервизора.

Поэтому у меня есть https://github.com/pg83/mix/blob/main/pkgs/bin/killd/cycle.sh - демон, убивающий "залетные" процессы. Если это полетит, то я это, конечно, добавлю в свой init.

Кстати, убиение через SIGINT там исключительно потому, что, если sway убить через SIGKILL, то он регулярно вешает систему намертво. Вот такой классный графический стек в Linux.

К сожалению, тот же sway зачем-то запускает все процессы через double fork. К счастью, исправление - 3 строки кода.

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

Че-то уже третья новость про обновление uutils. Я имею сказать:

* Несмотря на все вбуханные усилия, среднестатичтический configure пока не работает(ну, ладно, на состояние 2 месяца назад).

* Размер busybox-style статического бинаря для busybox - 1.5MB, coreutils - 2.5MB, uutils - 10MB(опять же, на состояние пару месяцев назад, сейчас проверить не могу, потому что Rust у меня уже не запускается). Надо еще понимать, что в busybox в 3 раза больше утилит, там и cron, и dhcp, и util-linux, и так далее. Но они вообще упоротые, читать их код очень интересно.

* Зачем переписывать простой код, который и память-то особо не выделяет, я не понимаю. Какой от этого added value?

Обещал тут написать про модель безопасности. #seq_model #gold

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

* Удобно рассматривать эту модель как двухпользовательскую - root + user, факт, что какие-то там системные процессы запущены от nobody фактически ничего не меняет.

* Все ценные данные на вашем ноутбуке принадлежат вашему личному аккаунту. Кредитки, пароли, ключи доступа. root владеет лишь системными файлами и демонами.

* Поэтому, если вредонос получает доступ к вашему пользователю, то он получает доступ ко всему полезному содержимому вашего компьютера. Заполучить root права НЕ ЯВЛЯЕТСЯ целью атаки. root в такой системе ни для чего не нужен, не нужен даже для запуска регулярного фонового процесса, потому что в любой современной OS есть сессионные пользовательские супервизоры процессов. Скажем, dbus.

* Скрыть свое присутствие - это тоже не про root, BTW, это немного другие дыры в системе.

Отсюда интересное следствие.

Удобно рассматривать root не как пользователя, который может все, а как способ разделить опасные операции, которые требуют подтверждения, и на все остальные. То есть, sudo в такой системе - это не эскалация привилегий, а подпись, что текущую команду ты запускаешь, понимая, что она делает. Ну и, соответсвенно, гарантия, что обычный rm -rf $STEAM_ROOT/ не снесет весь корень(https://github.com/ValveSoftware/steam-for-linux/issues/3671)(да, я знаю, что щас rm -rf / работает несколько не так).

Соответственно, у меня довольно наплевательское отношение ко всяким там CVE для #system0. Классно, конечно, что там какой-то проезд позволяет локально получить рута, но я надеюсь, что я сумел объяснить, что иногда от этого не горячо и не холодно.

Отдельная тема - где же тогда лежит периметр безопасности в вашем ноутбуке. Ответ достаточно очевидный - он лежит в вашем браузере. Софт вы качаете из сторов, всякое говно из интернетов не запускаете. Периметр - в sandboxing кода, выполняющегося в браузере. В обработке картинок браузером. И так далее. Браузер надо любить, холить, обновлять. Браузер единственная(ну, ладно, еще sshd) программа в системе, которую я вижу смысл облизывать с точки зрения безопасности - всякие там libc hardening, ASLR(pic), etc.

И ужу точно не в вашем /etc.

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

Почему не про BYOD? Потому что в BYOD 3 пользователя, вы, root, и товарищ майор(которому надо и скрыть свое присутствие для зловреда, и обнаружить такогого). Тоже интересная модель, но как нить в другой раз.

Двухпользовательский компьютер с антивирусом, кстати, тоже немного другая модель. Антивирус я не использую, считаю штукой, в среднем(лекарство хуже болезни), вредной.

Я тут допиливал свою поддержку sudo, которая, как вы помните, сделана поверх ssh #system0

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

Сломал голову, почему добавление в /etc/dropbear/authorized_keys (а я использую dropbear для серверной части, и openssh для клиента(потому что dropbear не поддерживает все нужные форматы ключей)) не решает мою проблему. Логи, потом strace - ну не читает демон /etc/dropbear/*, и все тут.

https://github.com/mkj/dropbear/blob/master/svr-authpubkey.c#L448 - вот код, этот файл он и читает.

В интернете написано, что читает /etc/dropbear. Кому верить?

Короче, в интернете пишут про dropbear в openwrt, где он широко используется, и там разработчики просто добавили поддержку нового пути - https://github.com/openwrt/openwrt/blob/openwrt-21.02/package/network/services/dropbear/patches/100-pubkey_path.patch , а стоковый не умеет, такие дела.

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

Вот мой патч на 3 строчки кода. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/sud/server/mix.sh#L12

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

Вообще, у меня внутри себя есть такой контест - как можно более маленьким патчем получить то, что мне нужно от кода.

Примеры:

* https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/lua/t/mix.sh#L21 - поддержка статически собранных с lua модулей

* https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/mesa/mix.sh#L36 - поддержка в экспортируемом API от #mesa полного opengl, вместо glesv2.

Последнее, кстати, очень интересная тема сама по себе.

Mesa умеет в полный opengl, но его полная реализация завязана на X, и экспортируется вместе с кодом поддержки X сервера. Если собирать только под Wayland, без поддержки X, эта либа просто не имеет шансов собраться, хотя внутри Mesa и имеет все необходимые запчасти для opengl.

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

Как это работает, рассказывать не буду, интересно - загляните внутрь, в Mesa это место довольно интересно устроено(как один и тот же внутренний код умееет притворяться для клиентов и glesv2, и opengl).

Вот код в mesa, который собирает glx - либу, которая неразрывно связывает opengl, и X11 - https://github.com/mesa3d/mesa/tree/main/src/glx

Я строю #system0 без systemd, но я считаю, что для десктопа нужна общая шина.

Соображения мои такие:

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

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

Поэтому я считаю, что dbus и polkit - здравые, по своей сути, идеи.

Но, как обычно, реализация у них всратая.

Я даже молчу, что у dbus настройки через xml, и ни с чем не совместимый и уникальный wire формат. Хотя и считаю правильным, чтобы там был \n-delimited json, чтобы сервисы можно было делать в виде скриптов на любом языке, и на любой чих(*). Для dbus запилить сервис это то еще удовольствие.

Я про то, что, хотя dbus и определяет wire format, но он не определяет стандартные интерфейсы.

Поэтому что ConnMann, что iwd, что NetworkManager - они не реализуют стандартный интерфейс по настройке сети, они реализуют свои, уникальные, интерфейсы.

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

Есть такой набор стандартов от XDG, классная штука. Но они, например, предлагают использовать https://linux.die.net/man/1/xdg-open для того, чтобы открывать файлы и урлы на простмотр.

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

Интересно, GNOME и KDE сумели договориться про общие интерфейсы в этом месте? А про global menu? :)

Кстати, тот факт, что каждый sway пишет себе свой swaymsg, вместо того, чтобы использовать общую шину, это тоже камешек в огород десктопному Linux.

Настраивать каждое сочетание compositor + нотификацию + пользовательские программы приходится своим, особенным, образом, вместо того, чтобы 1 раз и навсегда написать набор шелл-скриптов, которые бы дергала сессионная шина по тем или иным запросам приложений.

*: Именно поэтому протокол должен быть простой, чтобы скрипт мог его реализовать через pipe + jq.