The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Раздел полезных советов: Улучшение безопасности sources.list..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Улучшение безопасности sources.list..."  +/
Сообщение от auto_tips (??), 03-Сен-19, 14:42 
Опция "signed-by" привязывает доверенный публичный ключ к репозиторию, что блокирует установку ПО в случае, если InRelease подписан другим ключом. Опция может быть установлена как в fingerprint ключа, так и в форме пути к файлу.

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

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

2. допустим, что есть репозиторий, доступный по безопасному каналу, чей приватный ключ был скомпромитирован;

3. оба репозитория прописаны в sources.list и оба ключа добавлены в доверенные.

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

Поэтому в https://wiki.debian.org/DebianRepository/UseThirdParty рекомендуется прописывать всем сторонним репозиториям "signed-by", при этом указано использовать путь к ключу вместо fingerprint-а.

По моему мнению, имеет смысл прописывать signed-by вообще всем репозиториям.

В дистрибутивах, использующих APT, почему-то по умолчанию не используется опция signed-by. В инструкциях по подключению других репозиториев тоже почти никогда не встречаются указания её использовать.

Так как ручная идентификация ключей для каждого репозитория - дело трудоёмкое, был подготовлен [[https://gitlab.com/KOLANICH/AptSourcesHardener.py скрипт]], разбирающий sources.list, автоматически идентифицирующий fingerprint-ы и файлы ключей для каждого репозитория и выдающий модифицированный sources.list для сравнения с оригинальным.

В скрипте используется [[https://gitlab.com/KOLANICH/AptSourcesHardener.py собственная библиотека]] для парсинга и сериализации sources.list на основе грамматики для [[https://github.com/igordejanovic/parglare parglare]].


URL: https://gitlab.com/KOLANICH/AptSourcesHardener.py
Обсуждается: https://www.opennet.ru/tips/info/3117.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Улучшение безопасности sources.list в дистрибутивах, использ..."  +/
Сообщение от Аноним (1), 03-Сен-19, 14:42 
итого для вашей безопастносте следует срочно-срочно запустить скрипт от Коляна с использованием самодельной нескучной библиотечки.

а то ж текущие системные конфиги - небезопастны,небезопастны!

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Улучшение безопасности sources.list в дистрибутивах, использ..."  +/
Сообщение от Аноним (7), 17-Сен-19, 22:46 
Скрипт не такой большой, вместо нытья мог бы и прочитать исходники. Библиотека parglare больше, но опять же RTFSC.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Улучшение безопасности sources.list в дистрибутивах, использ..."  +/
Сообщение от Аноним (2), 03-Сен-19, 17:07 
Ох и наговнокодил ты, хотя бы предупреждал бы что модно измазаться если открыть.

Глупая статься и ещё более глупый код, фу таким быть...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Улучшение безопасности sources.list в дистрибутивах, использ..."  +/
Сообщение от Аноним (7), 17-Сен-19, 23:03 
То что там гoвнoкод было явно предупреждено, все претензии к цензуре на ресурсе.
Вылизывать архитектуру этого скрипта я не стал (ИМХО для этого скрипта не имеет смысла особого), просто допилил до минимально юзабельного состояния. Простор для улучшений огромен (напр. переписать грамматику на CoCo/R (работает на порядки быстрее, чем parglare, так как parglare генерит грамматику в json и потом интерпретирует её кодом на питоне, а CoCo/Py генерит сразу питоний код) и приделать экспорт сертификатов в файлы), репозиторий на GitLab, функция пулл-реквестов включена.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

11. "Улучшение безопасности sources.list в дистрибутивах, использ..."  +/
Сообщение от Аноним (-), 03-Дек-19, 18:23 
Чего ты от питониста ожидал? Это как проги под винды на VB, low entry barrier language жэ.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Улучшение безопасности sources.list в дистрибутивах, использ..."  +/
Сообщение от Аноним (3), 03-Сен-19, 19:17 
>допустим, что есть репозиторий, доступный по скомпрометированному каналу

переключаемся на https?

>чей приватный ключ был скомпромитирован;

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Улучшение безопасности sources.list в дистрибутивах, использ..."  +/
Сообщение от Онаним (?), 08-Сен-19, 09:15 
Там толк от HTTPS нулевой. Пакеты все подписаны и проверяются при установке.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Улучшение безопасности sources.list в дистрибутивах, использ..."  +/
Сообщение от Аноним (6), 08-Сен-19, 21:25 
ну так тут описывается ситуация, что для нормального репозитория, который качают по скомпрометированному каналу, пакеты подменяются на нечто, подписанное ключом скомпрометированного репозитория. Переход на HTTPS, по идее, это не позволит сделать, хотя уровень компрометации тут не описывается.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

12. "Улучшение безопасности sources.list в дистрибутивах, использ..."  +/
Сообщение от Аноним (-), 03-Дек-19, 18:26 
> переключаемся на https?

У дебиана onion есть. Там мало того что end to end шифрование, так атакующему еще и довольно трудно канал атаковать. И не видно какие пакеты каких версий качали, что полезно от прицельных атак на конкретные версии софта.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

9. "Улучшение безопасности sources.list в дистрибутивах, использ..."  +/
Сообщение от Аноним (9), 19-Сен-19, 17:57 
Где взять нескомпроментированные публичные ключи для gpg и сертификаты для https?

2 идеи о проверке исходников и системе повторяемых сборок: https://www.linux.org.ru/forum/admin/15194240?cid=15199687

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Улучшение безопасности sources.list в дистрибутивах, использ..."  +/
Сообщение от InuYasha (?), 01-Дек-19, 12:52 
Хотел сделать это руками для двух репов, но пока облом: ключи приходят в текстовом формате, .gpg-файлы нужны бинарные, апт хранит trusted-ключи вообще в одном файле, хотя может и в папке. Причём есть как /etc/apt/trusted.gpg.d , так и /usr/share/keyrings. Не сказал бы что в этом просто разобраться за полчаса.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Ihor
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2019 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру