Как я могу подтвердить, что двоичные файлы в моем Ubuntu взяты из исходного кода, из которого они должны быть?


25

Как и 99% пользователей, я устанавливаю Ubuntu из готовых двоичных файлов.

Как я могу убедиться, что эти двоичные файлы на самом деле взяты из исходного исходного кода Ubuntu?

Было бы хорошо проверить, что АНБ / кто-то еще не сотрудничал ни с Ubuntu, ни с Linode (моим провайдером VPS), чтобы связываться с двоичными файлами. Если бы мы могли проверить двоичные файлы, они также вряд ли попытались бы сделать это в первую очередь, так как было бы легко их вызвать.


Вы можете взглянуть на исходный код, использовать apt-get sourceили использовать его для компиляции своего собственного. Смотрите этот вопрос: askubuntu.com/questions/28372/…
Уилф

4
Возможно, полезно: Как проверить, что установленные файлы пакета соответствуют оригиналам? (Debian, но должен быть достаточно близко, чтобы быть применимым к Ubuntu)
CVn

@ MichaelKjörling Я искал нашу версию этого вопроса ...
Брайам

1
@Braiam Я думаю, что в данном конкретном случае Debian / Ubuntu не имеет большого значения. Что имеет значение, так это цель вопросов; приведенный выше ориентирован в первую очередь на обнаружение поврежденных файлов в какой-то момент после установки, тогда как этот, похоже, нацелен на обнаружение злонамеренно замененных или измененных файлов или двоичных файлов, не соответствующих предполагаемому исходному коду. Разные проблемы, поэтому я пометил ссылку только «возможно, полезно».
CVn

3
Интересно, что я думаю, что даже Gentoo полностью избегает этой проблемы: там вы должны доверять загруженным архивам исходного кода. Используйте криптографические подписи все, что вы хотите; если вы не можете доверять тому, что подписанное является подлинным и что оно является тем, чем оно должно быть, на самом деле мало что можно сделать.
CVn

Ответы:


36

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

Так...

  1. после загрузки исходного кода,
  2. Вы должны проверить весь код,
  3. и затем скомпилируйте это!

Но подождите - вы можете доверять компилятору ?


15
"Можете ли вы доверять компилятору?" Именно тогда вы начинаете изучать касательные и читаете вопрос « Как скомпилировать компилятор C с нуля, а затем скомпилировать Unix / Linux с нуля (и связанные с ним ответы).
CVn

17
Но можете ли вы доверять своему оборудованию? Возможно, вам также следует создать свой компьютер с нуля, и вот тут вы столкнетесь с несколькими проблемами ...
Томас

И можете ли вы доверять гипервизору, на котором установлена ​​ваша виртуальная машина?
Фернандо Коррейя,

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

6
Но подождите - можете ли вы поверить, что Аскубунту не фильтруется и не полностью контролируется АНБ, чтобы не рассказать вам обо всех потенциально скомпрометированных областях?
TheZ

9

Если вы не готовы принять «потому что Ubuntu так говорит», то вы не можете.


2
Я бы добавил, что вы можете [попытаться] проверить, соответствуют ли двоичные файлы в вашей конкретной системе исходным двоичным файлам Ubuntu, сравнивая контрольные суммы. Конечно, правильный руткит не может быть легко обнаружен внутри системы в любом случае.
Петерис

2
Это работает, только если вы уверены, что «оригинальные двоичные файлы Ubuntu» не были подделаны. Другими словами, если вы признаете, что они хороши, потому что Ubuntu так говорит. ;)
фкраием

5

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

Причина в том, что очень трудно получить точно такие же двоичные файлы, какие есть в скомпилированных пакетах, поскольку они зависят от точной версии компилятора, его параметров, и, вероятно, также есть некоторые пути или переменные среды, скомпилированные в двоичный файл. Таким образом, вы не сможете получить точно такой же двоичный файл при компиляции, который «проверит» загруженный двоичный файл.

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

Тем не менее, ручное сравнение загруженного двоичного файла и самоскомпилированного может обнаружить добавленный / измененный код, поэтому было бы рискованно, если кто-то предлагает двоичные файлы и исходный код, чтобы что-то скрыть в двоичных файлах, поскольку это может быть обнаружено.

Но есть проблема доверия к компилятору, как уже упоминалось ...


4

Трудно создать одинаковые двоичные файлы на двух разных компьютерах. Проект TOR делает это как обычную часть их сборки. Есть описание, как они это делают. У Debian и Fedora, кажется, есть проекты, делающие это возможным для этих дистрибутивов, но они находятся на ранних стадиях. Это не похоже , есть какая - либо работа , проделанная в Ubuntu .

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


Подробности о том, что конкретно?
Йозеф

Проигнорируйте меня, перепутал с другим сообщением :)
Тим

0

Проверка с помощью Ubuntu MD5. Если MD5, который вы получаете из ваших файлов, совпадает с тем, который опубликовал Ubuntu, то никто не вмешивался в двоичные файлы между ними.


Это не вопрос ОП. Он обеспокоен тем, что исходный код, распространяемый Ubuntu, не совпадает с двоичными файлами, распространяемыми Ubuntu. Другими словами, они говорят «это источник», но источник, из которого они строят двоичные файлы, на самом деле имеет некоторый дополнительный код, представленный АНБ. Он не беспокоится, что двоичные файлы были изменены после сборки.
Джон Златоуст

ОП написал: «Как я могу убедиться, что эти двоичные файлы на самом деле взяты из исходного исходного кода Ubuntu?» Ответ на этот вопрос. Другой - просто смешно: кто знает, легко ли кто-нибудь вмешался в ядро ​​Linux (АНБ или кто-нибудь еще?), Скачайте код, прочитайте его и, как только вы будете счастливы, скомпилируйте его самостоятельно. Кроме этого, мой ответ на вопрос, который я скопировал в начале этого комментария.
YoMismo

Вы не ответили на вопрос, который вы цитировали. Использование MD5 только позволяет ему проверить, что двоичные файлы на его компьютере соответствуют двоичным файлам на сервере. Они НЕ позволяют ему проверять, что загруженные им двоичные файлы были скомпилированы из исходного кода, который предоставляет Ubuntu. Теперь я согласен, что его вопросы смешны по той причине, которую вы (и другие) изложили. Но это был его вопрос.
Иоанн Златоуст

0

Это тяжелая работа, я думаю, что доверие здесь лучше, чем эта сложная работа. Но вопрос Можете ли вы доверять?

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

Давайте сделаем сценарий для этой цели, я хочу проверить, что Ubuntu == source code, подожди, почему ты не пытаешься сравнить пакеты с их источником?

  1. Создайте бинарный пакет для Ubuntu из исходного кода.
  2. сравнил самодельный двоичный пакет с пакетом, опубликованным дистрибутивом.
  3. Используйте apt-get -b source для загрузки исходного кода.

Но для меня сравнение хорошо дает незначительные результаты из-за разных временных меток, сред, но разве это доказывает, что это не из исходного кода!

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.