LINUX.ORG.RU

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

 ,


1

1

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

В Debian, например, уже много лет по дефолту включен SecureApt (а ключи разделены между разработчиками при помощи Shamir's Secret Sharing Scheme). Для того чтобы быть уверенным в подлинности апдейтов, достаточно лишь проверить цифровую подпись для скачиваемой ISO'шки.

Есть emerge-webrsync который умеет проверять скачанный снэпшот с ебилдами, но чтобы он это делал, необходимо ставить и настраивать GnuPG, а также добавлять соответствующие настройки make.conf.

Почему в Gentoo это не делается искоробки (казалось бы, вся инфраструктура уже имеется)? Возможно кто-нибудь кинет в меня соответствующим тикетом в багзилле проекта?

★★★★★

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

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

anonymous ()

При установке 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 потому что и сам факт подлога и скомпрометированное звено выявляется элементарно.

init_6 ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

init_6 ★★★★★ ()
Ответ на: комментарий от init_6

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

init_6 ★★★★★ ()
Ответ на: комментарий от init_6

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

init_6 ★★★★★ ()
Ответ на: комментарий от anonymous

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

vurdalak ★★★★★ ()
Ответ на: комментарий от init_6

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

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

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

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

edigaryev ★★★★★ ()
Ответ на: комментарий от Pinkbyte

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

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

edigaryev ★★★★★ ()
Ответ на: комментарий от edigaryev

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

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

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.

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от edigaryev

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

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

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

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

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

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

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

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

init_6 ★★★★★ ()
Ответ на: комментарий от Pinkbyte

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

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

init_6 ★★★★★ ()

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

emulek ()
Ответ на: комментарий от init_6

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от init_6

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

anonymous ()
Ответ на: комментарий от init_6

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от Pinkbyte

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

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

edigaryev ★★★★★ ()
Ответ на: комментарий от init_6

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

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

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

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

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

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

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

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

edigaryev ★★★★★ ()
Ответ на: комментарий от edigaryev

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от edigaryev

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

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

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

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

$ qlist portage | grep gpg | wc -l 0

Ещё вопросы?

anonymous ()
Ответ на: комментарий от anonymous
$ qlist portage | grep gpg | wc -l
0

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

anonymous ()
Ответ на: комментарий от anonymous

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. Как я уже говорил, автоматизация - в процессе.

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

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

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

edigaryev ★★★★★ ()
Ответ на: комментарий от edigaryev

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

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

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

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

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

likely

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

vurdalak ★★★★★ ()
Ответ на: комментарий от vurdalak

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

anonymous ()
Ответ на: комментарий от anonymous

Дроббинс?

Ага.

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

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

vurdalak ★★★★★ ()
Ответ на: комментарий от vurdalak

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

anonymous ()
Ответ на: комментарий от Pinkbyte

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

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

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

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

edigaryev ★★★★★ ()
Ответ на: комментарий от edigaryev

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

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

Pinkbyte ★★★★★ ()

Просто оставлю это здесь: 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.

edigaryev ★★★★★ ()

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

bryak ★★★ ()
Последнее исправление: bryak (всего исправлений: 1)
Ответ на: комментарий от bryak

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

https://wiki.debian.org/ReproducibleBuilds

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

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

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

edigaryev ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.