Gentoo и небезопасный emerge --sync

Манифесты всех пакетов уже подписаны ключами разработчиков. При желании ты можешь их проверить. Также ведётся разработка проекта Gentoo-keys для упрощения процедуры проверки.

А почему emerge автоматически их не проверяет? Шёл 2014 год.

При установке Gentoo предполагается что дерево ебилдов получено по надежному каналу, в противном случае достаточно тривиально устроить MITM, и в результате пользователь скомпиляет у себя ядро/Firefox/etc. с патчами от Three Letter Agency.

Там-же рядом с ebuild-ами есть и забавный файлик Manifest содержащий в себе контрольные суммы файлов и подпись ключом которую можно элементарно проверить при помощи gpg --verify Manifest.

Этот ключ гарантирует что контрольные суммы прописанные в файле Manifest у пользователя такие-же как и у разработчика который подписал Manifest.

Для того чтобы твой MITM полноценно сработал нужно завладеть сервером некоего открытого проекта на который разместить «счастье»(1) затем нужно скомпрометировать ключ разработчика(2) да еще и в довесок запихнуть подправленные ebuild и Manifest в основное дерево(3). Ну допустим ты закинешь подправленные ebuild и Manifest на целевую систему и угадай что сделает первый же emerge --sync?

И вот возможно я не очень сильно параноик но выполнить (1), (2) и (3) лично мне кажется скажем так довольно затруднительным заданием. А не выполнив хоть один из этих пунктов грош-цена твоему MITM потому что и сам факт подлога и скомпрометированное звено выявляется элементарно.

А почему emerge автоматически их не проверяет? Шёл 2014 год.

А почему ты ленивая задница не создал баг в багзилле и не прикрепил туда патчи которые будут реализовать сабж? Видимо траллить на ЛОРе оно веселее и гораздо нужнее чем писать какие-то патчи для проверок каких-то там никому не нужных подписей.

зачем создавать баг, если у меня всё работает?

А почему emerge автоматически их не проверяет? Шёл 2014 год.

зачем создавать баг, если у меня всё работает?

Затем, что ещё не все разработчики gentoo осилили libastral.so…

И затем что устрани сперва логическое противоречие.

ты думаешь я буду пользоваться дистрибутивом с неподписанными репами?

ты думаешь я буду пользоваться дистрибутивом с неподписанными репами?

А ты думаешь мне не посрать чем ты там будешь пользоваться?

А с чем их сверять? Нужно чтобы где-то был доверенный эталон.

Там-же рядом с ebuild-ами есть и забавный файлик Manifest содержащий в себе контрольные суммы файлов и подпись ключом которую можно элементарно проверить при помощи gpg --verify Manifest.

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

Для того чтобы твой MITM полноценно сработал нужно завладеть сервером некоего открытого проекта на который разместить «счастье»(1) затем нужно скомпрометировать ключ разработчика(2) да еще и в довесок запихнуть подправленные ebuild и Manifest в основное дерево(3).

Ничего этого не нужно. Достаточно лишь поправить размер файла и хэш-суммы в Manifest, который передается открытым текстом во время emerge --sync (rsync). Ну и тривиальный HTTP MITM сделать, чтобы выдать пользователю «пропатченный» тарболл, когда он будет делать emerge packagename.

Манифесты всех пакетов уже подписаны ключами разработчиков. При желании ты можешь их проверить.

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

Надеюсь что это шутка

Не понял, что не так:

pinkbyte@phantom ~ $ cat /usr/portage/dev-libs/boost/Manifest | gpg >/dev/null 
gpg: Подпись создана Чт 04 сен 2014 13:13:24 MSK ключом RSA с ID 9DF76EBB
gpg: Действительная подпись от "Sergey Popov <admin@pinkbyte.ru>" [абсолютно]
gpg:                 aka "Sergey Popov (Old personal mail) <pinkbyte@mail.ru>" [абсолютно]
gpg:                 aka "Sergey Popov <pinkbyte@gentoo.org>" [абсолютно]

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

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

Ага а особенно в свете того, что некоторые считают что portage и так „неслабо тормозит во время подсчета зависимостей“ попоболь доходит до попыток форка.

Ничего этого не нужно.

А portage скачает с непропатченного чистого зеркала, контрольная сумма не сойдется и ebuild пошлют… Ня!

Достаточно лишь поправить размер файла и хэш-суммы в Manifest

Достаточно лишь diff „пропатченный“ Manifest с нормальным. К тому же у любого софта есть вэб адрес на который можно пойти… и не найти там нихрена в случае твоего „пропатченного“ поделия. И это же тоже не вызовет никакого подозрения.

Ну и тривиальный HTTP MITM сделать, чтобы выдать пользователю «пропатченный» тарболл, когда он будет делать emerge packagename.

Ну и в результате тривиальный паяльник решает эффективнее твоего „простого MITM“ которое трещит по швам и во всех направлениях.

Автоматизацией этого процесса(и не только) и занимается проект gentoo-keys.

Не знаю как они делают а я бы пихал проверку всех gpg в тот-же район что и emerge --metadata вот примерно куда-то туда.

наверное потому, что мало кто из пользователей осилит добавить ключи _всех_ разработчиков ПО(их Over9000). В бинарных дистрах можно доверять всего одной подписи маинтейнера(ов).

А keyring-и откуда брать? А верифицировать их на базе информации из LDAP-а, где зарегистрированы все разработчики?

ТС о том и пишет, что проверять каждый файлик ручками — идиотизм. Особенно в 2014 году.

Ага а особенно в свете того, что некоторые считают что portage и так „неслабо тормозит во время подсчета зависимостей“ попоболь доходит до попыток форка.

Это повод починить portage, шифрование тут не при чем.

А portage скачает с непропатченного чистого зеркала, контрольная сумма не сойдется и ebuild пошлют… Ня!

Ты в курсе, что такое MITM? Трафик, идущий с чистого зеркала, сперва изменяется третьей стороной. Изменяются, в том числе, и контрольные суммы. Увы и ах. Ещё есть DNS spoofing. Ну и много других способов.

Достаточно лишь diff „пропатченный“ Manifest с нормальным. К тому же у любого софта есть вэб адрес на который можно пойти… и не найти там нихрена в случае твоего „пропатченного“ поделия. И это же тоже не вызовет никакого подозрения.

Серьезно? Ты реально подобным занимаешься?

Этот проект делит все приемущества централизованного Gentoo Portage на ноль.

Если пользователь проверяет подлинность софта таким образом (для каждого пакета), зачем ему доверять каким-то там ноунейм писателям ебилдов, если можно доверять непосредственно разработчику софта и одновременно собирать весьма ценный кейчейн, который потом пригодится в любом другом дистрибутиве/ОС?

Ага а особенно в свете того, что некоторые считают что portage и так „неслабо тормозит во время подсчета зависимостей“ попоболь доходит до попыток форка.

По теме-то есть что сказать?

А portage скачает с непропатченного чистого зеркала, контрольная сумма не сойдется и ebuild пошлют… Ня!

Аргумент в стиле «а вот упадет метеорит на дом пользователя, и MITM не сработает».

Достаточно лишь diff „пропатченный“ Manifest с нормальным. К тому же у любого софта есть вэб адрес на который можно пойти… и не найти там нихрена в случае твоего „пропатченного“ поделия. И это же тоже не вызовет никакого подозрения.

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

Ну и в результате тривиальный паяльник решает эффективнее твоего „простого MITM“ которое трещит по швам и во всех направлениях.

Хм, ты случаем не фанбой Gentoo?

Ничего не мешает тебе проверять скачиваемые тарболлы, если апстрим предоставляет их цифровые подписи

Кто сказал slackware?

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

Ээээ, то есть тот, кому нужно провести атаку, должен спереть минимум 1 ключ разработчика и подписать им манифест нужного пакета.

Ничего сложного, на самом деле, да-да-да...

Если есть идея как улучшить безопасность - мы жаждем услышать её в нашем мэйллисте gentoo-dev. Желательно в виде GLEP-а и/или с референсной реализацией.

И тебе того же

$ qlist portage | grep gpg | wc -l 0

Ещё вопросы?

$ qlist portage | grep gpg | wc -l
0

Ну вот, весь драматизм ситуации к черту. Но суть особо не меняется.

It has been decided that binary keyrings will also be made available for distribution. Most likely installed via ebuild. It will also be likely to be updated via gentoo-keys built-in checks and update functions.

Цитата со страницы проекта gentoo-keys. Как я уже говорил, автоматизация - в процессе.

Ээээ, то есть тот, кому нужно провести атаку, должен спереть минимум 1 ключ разработчика и подписать им манифест нужного пакета.

Вы что, сговорились? Цифровая подпись манифеста ПО ДЕФОЛТУ не проверяется, ничего переть не нужно.

Цифровая подпись манифеста ПО ДЕФОЛТУ не проверяется, ничего переть не нужно.

Да сколько ж повторять можно-то, госспади

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

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

Обобщу: или помогай или не мешай

likely

О чем ТС и говорит. На дворе 2014 год, а у гентушников все ещё likely :)

Проблема, на самом деле, в том, что с гентушниками очень сложно работать. Поэтому генту уже три раза форкнули. Один из форков делал её основатель :)

Основатель ещё более упорот, чем остальные гентушники.

Дроббинс? С ним можно работать. И тот же openrc в funtoo более вменяем (например, ты можешь сделать /etc/init.d/net.br0.work и /etc/init.d/net.br0.home). И наличие всяких вкусняшек в духе debian-sources. И git вместо cvs/rsync.

Дроббинс?

Ага.

С ним можно работать.

Со всеми можно работать. Но упоротости это не отменяет.

Нет, с Хаббсом работать не получается.

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

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

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

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

Причём здесь оборонительная позиция - я уже говорил что это всё пилится(проект gentoo-keys), только на это не хватает рук.

А учитывая что всё это завязано на миграцию с CVS на Git...

Просто оставлю это здесь: https://forums.gentoo.org/viewtopic-t-998800.html

По ссылке разработчики Gentoo обсуждают сабж (2014 год).

The rsync approach is bad and should be killed with fire. It's inherently insecure. Everyone who does not use «emerge-webrsync» with gpg signature check should think twice about what he is doing.

Кто-нибудь, расскажите им про rsync over SSH.

Есть подвижки: https://www.gentoo.org/news/2015/08/12/git-migration.html

In regards to package signing, the migration will streamline how GPG keys are used. This will allow end-to-end signature tracking from the developer to the final repository, as outlined in GLEP 57 et seq.

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

любой мейнтейнер может собрать сорс с закладкой, подписать его и выложить в репу и все его заюзают

https://wiki.debian.org/ReproducibleBuilds

Опенсорс предоставляется без каких-либо гарантий.

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

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