Подписывание бинарников

[vitus_wagner]

Вот интересно, почему проект DigSig сдох почти десять лет назад, а от bsign-а вообще следов не найдешь, кроме как в древних-древних архивах дебиана и убунты?

В принципе ж классная идея. Намного лучше чем всякие aide и integrit.

Особенно если вместо gpg-шных подписей туда положить CMS-ные. Ну и соответствующую ключевую инфраструктуру выстроить (ровно ту, которая у меня в Детях Пространства описана - корень доверия - ключ владельца компьютера, который выписывает на ключ производителя дистрибутива сертификат с pathLen=1).

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

Comments

[tzirechnoy [lj.rossia.org]]

libdl переписывать? Можно.

[vitus_wagner]

Уже переписали в рамках проекта DSig. И даже работает.

[filin]

... причем верификация тремя разными бинарниками, написанными на языках с _различными_ компиляторами в нативный код.

[vitus_wagner]

Зачем? UEFI проееряет подпись под grub, grub под ядром, ядро под всеми остальными бинарниками.

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

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

[filin]

Ты ведь должен быть в курсе понятия "эшелонированная оборона"...

[vitus_wagner]

По-моему, тут не в эту сторону эшелонировать оборону надо.

На самом деле здесь ОЧЕНЬ критична производительность процедуры проверки подписи. Если мы верифицируем каждый загружаемый бинарник, включая открываемые dlopen-ом, это может начать кушать заметные ресурсы, особенно при наличии короткоживущих процессов вроде CGI.

[filin]

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

И это не специальная система админа, которую можно засекьюрить очень изрядно. Если изрядо засекьюрить систему разработчика, разработка встанет.

[vitus_wagner]

Тут же-то он зачем лежит? Если у разработчика проверка подписи выключена, то на этой машине ключа и не должно быть. А должен быть этот ключ там где buildd работает и собирает пакеты, предназначенные для распространения.

Но вообще по хорошему счету, система должна поддеривать контейнеры с неподписанными бинарниками (но, естественно, не ядерными модулями).

Тогда браузить веб разработчик сможет из системы с подписанными бинарниками. А разрабатывать - с неподписанными.

Хотя, честно сказать не уверен что разработка действительно встанет. Добавить в Makefile одну строчку - несложно.

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

[lumag]

Можно оживить DigSig. Вернее переосмыслить и переписать его. В ядре есть проверка PKCS#7 для загрузки модулей, работа с сертификатами и т.п. Можно переиспользовать эти компоненты. Вопрос, кому это будет полезно, кто будет реально пользоваться этой возможностью. Удастся ли, например, убедить Debian, Canonical или RH начать подписывать бинари.

[vitus_wagner]

Ну я знаю по крайней мере один Debian-based дистрибутив, где DigSig используется. Опционально, правда, надо специально включать. Собственно из-за того что пришлось с этим поиграться. возник и вопрос - почему оно такое малораспространенное.

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

Для того use case, который рассматриваю я - менеджмент толп контейнеров и серверов, это приемлемые затраты.

И нужен дизайн правильной PKI и поддержка ее в инсталляторе.

Потому что в случае свободного ПО рутом PKI должен быть владелец компьютера и никто другой.

[lumag]

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

Про PKI. Я не думаю, что в данном случае нужна именно древовидная структура. Я бы делал одноуровневый keyring. Т.е. владелец может добавить свои ключи, может выкинуть дистрибутивный ключ и подменить своим, но это все без PKI. Подход apt-key проще и понятнее большинству.

[golosptic]

1) А что это за дистрибутив?
2) Можно придумать signing proxy. А велика ли с Вашей т.з. трудоёмкость?

[golosptic]

Насколько, с Вашей точки зрения, была бы трудоёмкой такая задача?

[vitus_wagner]

Которая из - оживить или убедить?

[lumag]

Я бы оценил в 2 MW до первого proof of concept, плюс 1 MM до минимально работающей версии, еще примерно 1.5–2 MM до объективно полноценной версии. Потом можно заниматься разными плюшками вида подборки вариантов кэширования, доведения до upstream и т.п.

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

[avnik]

Я бы скорее смотрел в сторону reproducibility builds, и соотвественно система сможет представлять из себя честный content addressable storage).

А с подписями как вы предлагаете будет одна проблема -- пакет собраный на сборочной ферме и пакет собраный локально из одних исходников будут _разные_, и именно в силу того, что у нас разные ключи на ферме и в локальном сборщике (а всякие signing proxy это только усугубят).

То есть надо как-то комбинировать зашитые в elf подписи, и detachable подписи.
(и возможно уметь смотреть на чексумму бинарника внутри fs (а приличная часть fs имеет внутреннее дерево хешей)

[lumag]

Да, с этой точки зрения тоже detachable signatures в плюсе получаются.

[hungry_ewok]

>Ну и соответствующую ключевую инфраструктуру выстроить

Тут недавно у владельцев шлемов окулус рифт их честно купленная техника превращалась в тыкву. Потому что ключевая инфраструктура и сертификаты, да...

[vitus_wagner]

Вот поэтому и надо уметь выстраивать ключевую инфраструктуру. а не доверять это вендорам.

[legolegs]

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

Во-первых, бинарники - это не то-же самое, что исполняемый код.

Во-вторых, исполныемый код - это есть то же самое, что и данные.

Надо ли подписывать *.py и *.sh? Как насчёт bash < котики.jpg и perl < рассказ.txt? Существуют невинные на первый взгляд файлы конфигурации с кодом, такие как ~/.xbindkeysrc. Конфиги все будем подписывать? Что будем делать с *.doc и другими форматами с макросами?

Есть, конечно, и другие способы *программировать* компьютер.

Недавно видел на ютубе, как путём манипуляций в игре Марио за счёт ошибок при подгрузке спрайтов в память была записана другая игра. С геймпада!

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

Более здравым (хотя практически трудноосуществомым) мне представляется путь формальной верификации программ в рамках source-based дистрибутива и, вероятно, отказ от тюринг-полных ЯП (для упрощения доказательств).

[vitus_wagner]

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

Правда, инструментов вроде aide, которые контролируют появление и исчезновение файлов, в полной мере не заменяет.

[legolegs]

>Оно решает задачу "гарантировать, что то, что пришло из дистрибутива, не подменили".

Разве подписи_пакетов+система_прав+драйвер_фс не решают эту задачу?

[golosptic]

Вот это вот путь формальной верификации программ в рамках source-based дистрибутива и, вероятно, отказ от тюринг-полных ЯП (для упрощения доказательств). конечно очень крутая история для такой темы, как "поболтать в курилке".

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

[lumag]

vitus_wagner, набросал мыслей на тему. Буду рад комментариям.

[vitus_wagner]

Вот доберусь до места с более-менее работающим интернетом...