The OpenNET Project / Index page

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

Улучшение безопасности sources.list в дистрибутивах, использующих APT
Опция "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. В инструкциях по подключению других репозиториев тоже почти никогда
не встречаются указания её использовать.

Так как ручная идентификация ключей для каждого репозитория - дело трудоёмкое,
был подготовлен скрипт, разбирающий sources.list, автоматически
идентифицирующий fingerprint-ы и файлы ключей для каждого репозитория и
выдающий модифицированный sources.list для сравнения с оригинальным.

В скрипте используется собственная библиотека для парсинга и сериализации
sources.list на основе грамматики для parglare.
 
01.09.2019 , Автор: KOLANICH , Источник: https://gitlab.com/KOLANICH/AptSour...
Ключи: sign, package, apt, debian
Раздел:    Корень / Администратору / Система / Linux специфика / Установка и работа с пакетами программ в Linux

Обсуждение [ RSS ]
  • 1.1, Аноним (1), 14:42, 03/09/2019 [ответить]  
  • +/
    итого для вашей безопастносте следует срочно-срочно запустить скрипт от Коляна с использованием самодельной нескучной библиотечки.

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

     
  • 1.2, Аноним (2), 17:07, 03/09/2019 [ответить]  
  • +/
    Ох и наговнокодил ты, хотя бы предупреждал бы что модно измазаться если открыть.

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

     
  • 1.3, Аноним (3), 19:17, 03/09/2019 [ответить]  
  • +/
    >допустим, что есть репозиторий, доступный по скомпрометированному каналу

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

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

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

     
     
  • 2.4, Онаним (?), 09:15, 08/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Там толк от HTTPS нулевой. Пакеты все подписаны и проверяются при установке.
     
     
  • 3.6, Аноним (6), 21:25, 08/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ну так тут описывается ситуация, что для нормального репозитория, который качают по скомпрометированному каналу, пакеты подменяются на нечто, подписанное ключом скомпрометированного репозитория. Переход на HTTPS, по идее, это не позволит сделать, хотя уровень компрометации тут не описывается.
     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




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

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