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

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

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

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

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

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

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

У меня 12.04, но я предполагаю, что на этот вопрос можно ответить более широко.

7
задан 4 January 2013 в 15:14

3 ответа

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

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

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

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

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

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

Можно читать больше о формате репозитория на Wiki 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 <cjwatson@chiark.greenend.org.uk>"
gpg:                 aka "Colin Watson <cjwatson@debian.org>"
gpg:                 aka "Colin Watson <cjwatson@ubuntu.com>"
gpg:                 aka "Colin Watson <cjwatson@canonical.com>"
$ 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 <ftpmaster@ubuntu.com>
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 <cdimage@ubuntu.com>

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) <ftpmaster@ubuntu.com>

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) <cdimage@ubuntu.com>

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

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

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

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

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

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

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

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

Все пакеты Ubuntu & PPA имеют источник в наличии, таким образом, они могут быть осмотрены любым.

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

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

Там известны нападения, или недавно были уязвимости?

Я вспоминаю один, ошибка Debian 499897. Debian обходит это путем предоставления Файлам версии даты окончания срока действия, после которой им нельзя доверять. Ubuntu еще не поддерживает это.

3
ответ дан 4 January 2013 в 15:14

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

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

0
ответ дан 4 January 2013 в 15:14

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

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

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

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

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

0
ответ дан 4 January 2013 в 15:14

Другие вопросы по тегам:

Похожие вопросы: