подмена обновлений ос и приложений

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

круто, в генте пакеты вроде не подписываются

torvn77, спасибо.

как проверить, какие отпечатки установлены у меня в системе? (нет ли недоверенных).

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

В общем если есть сомнение в образе то надо переставлять систему.

Ну а так есть какие то команды для верификации пакетов, почитай маны к командам семейства apt-* и команде dpkg, ну или жди пояснений от тех кто эти маны читал.

Вопрос второй. Если провайдер использует собственные dns сервера (они назначены в роутере через DHCP), то по сути он имет возможность проводить махинации?

Имея свой DNS, пров может выдать тебе другой ip-шник. Правда, если там https - то браузер ругнется на левый сертификат.

Как этого избежать?

Назначит DNS ручками. Не ходить на http-сайты.

Но, AFAIK, пров может и подменять DNS-ответы, тогда остается DNSSEC. Гуглоdns его умеет, по слухам. Но, если пров таки подменяет ответы, то при использовании dnssec у тебя просто перестанет работать dns.

apt-key list

круто, в генте пакеты вроде не подписываются

в генте работа строится по другому, см. https://wiki.gentoo.org/wiki/Handbook:Parts/Working/Features#Validated_Gentoo...

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

Ты только забыл написать, что это надо настраивать явно вручную, в 2к17-то, по дефолту решетище. И те снапшоты подписываются раз в сутки, как компромиссный вариант можно просто синкаться по git с зеркалом на жидхабе, там хоть https

Гуглоdns его умеет, по слухам.

dig @8.8.8.8 gentoo.org +dnssec
Судя по выхлопу умеет без слухов.

Ты только забыл написать, что это надо настраивать явно вручную, в 2к17-то, по дефолту решетище.

А что, в 2к17 генту ставят уже не по хендбуку «явно вручную»? Кто не хочет читать хендбук и делать - у того «по дефолту решетище», все правильно.

И те снапшоты подписываются раз в сутки

Снапшоты формируются и подписываются раз в сутки, все правильно.

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

А бинарные пакеты (собранные заранее в PORTAGE_BINHOST)?
не вижу слова signing:
https://wiki.gentoo.org/wiki/Binary_package_guide

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

А бинарные пакеты (собранные заранее в PORTAGE_BINHOST)?

Сомневаюсь, что сделают какую-то проверку и подпись пакетов «из коробки», потому как желающих делать реализацию нет. Все хотят пользовать уже готовое. :-D

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

apt-key list

показывает как доверенные ключи Opera и Yandex от приложений, которые я ставил год назад, и давно удалил. С какой стати?

Увы, хендбук надо читать весь вдоль и поперёк, думать, а уже потом ставить... просто читать и сразу делать — очень плохая идея. Сейчас хендбук лично мне напоминает обучение в школе и последующее обучение в вузе, когда после поступление в вуз в первую очередь говорят «забудьте, что вам говорили относительно <...> в школе, вам давали информацию в упрощенном виде». С одной стороны, такой подход оправдан (нет перегрузки информацией), с другой...

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

Hу почему, вы качаете подписанный снапшот, аналогично тому, как это делает webrsync c http://mirrors.kernel.org/gentoo/releases/snapshots/current/ проверяете, распаковываете, все, ничего синкать не надо. Вообще, странно, лет 7 или 8 назад в хендбуке точно помню посылали как раз по этой примерно ссылке качать снапшот и проверять его подпись...

Спасибо за ответы.

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

Браузер смотрит, во-первых, кем был выдан сертификат. Если корневой УЦ сертификата не добавлен в доверенные - будет ругаться. Ещё он сравнивает subject name сертификата с доменным именем сервера, к которому ты обращаешься.

откуда он знает, какие УЦ доверенные? Браузер уже идет со списком доверенных УЦ? Что мешает подделать subject name? Что мешает сертификат от Васи (левый) пометить как выданный Борей (доверенный).

откуда он знает, какие УЦ доверенные? Браузер уже идет со списком доверенных УЦ?

ЕМНИП, не браузер, а ось.

Что мешает подделать subject name? Что мешает сертификат от Васи (левый) пометить как выданный Борей (доверенный).

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

А подделать сертификат мешает отсутствие закрытого ключа УЦ, которым подписывается сертификат.

. Если провайдер использует собственные dns сервера (они назначены в роутере через DHCP), то по сути он имет возможность проводить махинации? Как этого избежать?

DNSCrypt, остальное уже ответили

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

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

Может, да. А может, нет.

Трояны же свои подписывала фальшиввми, но валидными сертификатами, пока не поймали за руку.

Трояны, AFAIR, и просто хацкерами подписывались.

И что?

PS Продолжая тему. Один из глобальных УЦ - Thawte, принадлежит Symantec. А сама Symantec, по слухам, тесно связана с АНБ и ЦРУ. Примерно, как Лаборатория Касперского с ФСБ :)

PPS А McAfee - с DOD :)

С такой, что они обновляются из своих репозиториев и добавляют их ключи в систему.

Не понял. Кто, что, откуда?

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

<чем больше вы скачиваете обновлений, тем больше глюков в линуксах

есть же debian stable, количество глюков не так велико.

<Я давно отказался от обновлений и ставлю с нуля новую версию

а как же обновления безопасности?

Держит ли ЦРУ закладки в репах Убунты?

но больше, чем в убунту

Я не до конца понял, ты пытался меня опровергнуть, или дополнить?

Каких только девиантов на лоре не встретишь.

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