Как узнать, что мои системные обновления заслуживают доверия?

7

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

  • процесс проверки обновлений будет показывать только законные обновления?
  • Обновления, которые я получаю и устанавливаю, не являются вредоносными?

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

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

Кроме того, я думаю, что пакеты криптографически подписаны, например, с GPG или аналогичным.

Правильны ли эти предположения? Где я могу проверить используемые ключи / сертификаты? Как я могу проверить, являются ли они правильными? Как я могу проверить, что они действительно используются? Существуют ли параметры конфигурации, которые делают процесс более или менее осмотрительным, и каковы его значения по умолчанию? Известны ли атаки или недавно были уязвимости? Кажется, я помню, что Windows уже давно столкнулась с такой проблемой.

Я на 12.04, но я предполагаю, что на это можно ответить в более общем плане.

    
задан Hanno Fietz 04.01.2013 в 11:03
источник

3 ответа

3

Это отличный вопрос. Ответ (конечно) довольно сложный, но позвольте мне попытаться сломать его для вас. Давайте сначала рассмотрим технические процессы:

Цепочка доверия

Мы не используем SSL для защиты APT, мы используем криптографические хэши (SHA256, в наши дни) и подписи OpenPGP. Это позволяет вам доверять ненадежным зеркалам и избегать необходимости доверять CA PKI.

Когда вы добавляете репозиторий в sources.list APT, вам также нужно добавить его ключ PGP в доверенную ключевую строку APT с командой apt-key . Брелок поставляется с ключами для репозиториев Ubuntu. И когда вы используете команду apt-add-repository для добавления PPA, она добавляет ключ (полученный от Launchpad через SSL) для вас.

Цепочка доверия:

  1. Каждая запись sources.list указывает APT на файл Release в репозитории, с сигнатурой Release.gpg (или их можно комбинировать в виде файла InRelease ). Этот файл описывает репозиторий и должен быть подписан ключом в вашей цепочке APT.
  2. Файл Release содержит криптографические хэши из всех файлов Packages и Sources . Они перечисляют все пакеты и версии, доступные в репозитории.
  3. Файлы Packages и Sources содержат криптографические хэши каждого пакета.
  4. Сами пакеты не подписаны. Это не нужно, есть цепочка доверия к ним, из файла Release, подписанного зеркалом. Однако исходные пакеты, используемые для сборки двоичных пакетов, подписываются PGP разработчиком, который их загрузил.

Подробнее о формате репозитория можно прочитать в вики-странице Debian .

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

Вы можете проверить брелок APT, запустив sudo apt-key finger .

Проверка архивных ключей Ubuntu

Откуда вы знаете, что должно быть там? Если вы не доверяете своему компьютеру, вы не можете доверять никаким программам на нем, чтобы не лгать вам (например, apt-key ), и это упражнение бесполезно. Итак, давайте предположим, что это просто академический интерес, и проверьте содержимое брелка из окончательного исходного пакета, который является PGP, подписанным разработчиком, который его загрузил.

Загрузите исходный пакет ubuntu-keyring и посмотрите, что должно быть там:

$ apt-get source ubuntu-keyring
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Need to get 20.0 kB of source archives.
Get:1 http://localhost/ubuntu/ quantal/main ubuntu-keyring 2012.05.19 (dsc) [1542 B]
Get:2 http://localhost/ubuntu/ quantal/main ubuntu-keyring 2012.05.19 (tar) [18.5 kB]
Fetched 20.0 kB in 0s (0 B/s)               
dpkg-source: info: extracting ubuntu-keyring in ubuntu-keyring-2012.05.19
dpkg-source: info: unpacking ubuntu-keyring_2012.05.19.tar.gz
$ gpg --verify ubuntu-keyring_2012.05.19.dsc
gpg: Signature made Sat May 19 03:33:12 2012 SAST
gpg:                using RSA key 0x393587D97D86500B
gpg: Good signature from "Colin Watson <[email protected]>"
gpg:                 aka "Colin Watson <[email protected]>"
gpg:                 aka "Colin Watson <[email protected]>"
gpg:                 aka "Colin Watson <[email protected]>"
$ gpg --no-default-keyring --keyring ubuntu-keyring-2012.05.19/keyrings/ubuntu-archive-keyring.gpg --fingerprint
ubuntu-keyring-2012.05.19/keyrings/ubuntu-archive-keyring.gpg
-------------------------------------------------------------
pub   1024D/0x40976EAF437D05B5 2004-09-12
      Key fingerprint = 6302 39CC 130E 1A7F D81A  27B1 4097 6EAF 437D 05B5
uid                            Ubuntu Archive Automatic Signing Key <[email protected]>
sub   2048g/0x251BEFF479164387 2004-09-12

pub   1024D/0x46181433FBB75451 2004-12-30
      Key fingerprint = C598 6B4F 1257 FFA8 6632  CBA7 4618 1433 FBB7 5451
uid                            Ubuntu CD Image Automatic Signing Key <[email protected]>

pub   4096R/0x3B4FE6ACC0B21F32 2012-05-11
      Key fingerprint = 790B C727 7767 219C 42C8  6F93 3B4F E6AC C0B2 1F32
uid                            Ubuntu Archive Automatic Signing Key (2012) <[email protected]>

pub   4096R/0xD94AA3F0EFE21092 2012-05-11
      Key fingerprint = 8439 38DF 228D 22F7 B374  2BC0 D94A A3F0 EFE2 1092
uid                            Ubuntu CD Image Automatic Signing Key (2012) <[email protected]>

Я знаю, что это на самом деле подпись Колина Уотсона, так как я встречался с ним несколько раз, и мы проверили личности друг друга и подписали ключи друг друга. Если у вас есть ключ в сильном наборе PGP, вы сможете найти для него доверительный путь. Я также знаю, что могу доверять ему, чтобы загрузить правильный пакет ubuntu-keyring .

Для Debian существует пакет ( debian-keyring ), содержащий ключи PGP всех разработчиков Debian, и вы можете использовать его для проверки подписей исходного пакета. У Ubuntu нет эквивалента, но многие разработчики Ubuntu также являются разработчиками Debian, и все ключи PGP нашего разработчика доступны в своих профилях в Launchpad.

Другие вопросы

  

Как узнать, что обновления не являются вредоносными?

Это сводится к доверию. Вы должны полностью доверять каждому используемому репозиторию. Вы предоставляете сторонним владельцам каждого разрешения на репозиторий запуск приложений с правами root на вашем компьютере.

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

Для обновлений после выпуска Ubuntu имеет строгие политики в отношении содержимого обновлений. Они должны содержать только минимальные исправления для исправления известных ошибок. Патчи проверяются членами групп SRU / Security до принятия.

Очевидно, что PPA и сторонние репозитории не имеют всех этих ограничений. Вы должны доверять владельцам PPA разумными.

Все Ubuntu & amp; Пакеты PPA имеют доступный источник, поэтому они могут быть проверены кем-либо.

  

Существуют ли параметры конфигурации, которые делают процесс более или менее осмотрительным и каковы его значения по умолчанию?

Вы можете отключить проверку подписи в APT, но, конечно, она включена по умолчанию. Когда вы пытаетесь установить что-то из неподписанного / ненадежного репозитория, apt заставляет вас подтвердить, что вы действительно хотите это сделать.

  

Известны ли атаки или недавно были уязвимости?

Я помню один, Ошибка 649897 в Debian.Debian оборачивается этим, предоставляя файлам Release дату истечения срока действия, после чего им нельзя доверять. Ubuntu пока не поддерживает .

    
ответ дан tumbleweed 12.01.2013 в 07:46
источник
4

Не существует SSL / https, о котором я знаю, и нет центра сертификации за пределами вашего собственного компьютера.

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

Используя этот индекс, ваш собственный компьютер рассчитает, какие новые пакеты необходимо загрузить. Опять же, пакеты будут восстановлены с использованием обычного http. Сумма md5 каждого пакета будет проверяться с помощью файла выпуска. Кроме того, также подписаны официальные пакеты репозиториев Ubuntu. У некоторых сторонних источников могут быть неподписанные пакеты (но проверка md5 по-прежнему используется), когда это произойдет, программа установки (apt, Ubuntu Software Center, ...) предупредит вас.

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

Более подробную информацию вы можете найти в объяснении безопасного apt здесь . Подводя итог: все пакеты имеют подпись GPG и apt доверяет те, которые были выпущены лицами, открытый ключ которых находится в apt keychain ( /etc/apt/trusted.gpg )

    
ответ дан Javier Rivera 04.01.2013 в 11:19
0

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

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

    
ответ дан 0xF2 08.01.2013 в 19:13