Источник APT для VPN: что он даёт и как его ограничить

Загрузка VPN-клиента — разовое решение; добавление его репозитория APT — нет. Второе сообщает менеджеру пакетов, откуда может появиться будущее программное обеспечение, и это постоянная передача полномочий, а не загрузка. Это может быть правильным устройством, когда поставщик должным образом поддерживает репозиторий. И всё же это заслуживает осознанного решения, а большинство инструкций по установке его пропускают.

Подпись удостоверяет архив, а не его код

APT проверяет подписанные метаданные репозитория, а затем доверяет контрольным суммам внутри этих метаданных для пакетов, которые он загружает. Это доказывает, что архив соответствует опубликованному владельцем ключа, и ничего не говорит о коде внутри. Правильно подписанный пакет всё ещё может содержать небезопасные скрипты сопровождающего, и эти скрипты выполняются от имени root во время установки пакета. Руководство apt-secure проводит именно эту границу между удостоверением архива и проверкой программного обеспечения.

Поэтому полезный вопрос не в том, действительна ли подпись, — сломанная подпись всё равно остановит установку. Вопрос в том, чьей подписи вы выбираете доверять с этого момента. Украденный ключ подписи хуже украденного пакета, потому что злоумышленник продолжает выпускать действительные метаданные ещё долго после первого плохого релиза. Единственное исправление — смена ключа, и она зависит от того, опубликует ли поставщик новый ключ по каналу, который вы можете проверить самостоятельно.

Именно поэтому идентичность ключа заслуживает не меньше внимания, чем URL репозитория. Ключ, взятый с адреса в старом ответе на форуме, ничего не доказывает об издателе, тогда как HTTPS защищает передачу до того, кто ответил по телефону. Безопасность передачи и идентичность издателя — разные вопросы, и только первый решается сертификатом.

Ограничьте ключ источником, а не системой

Современный APT принимает ссылку Signed-By, привязанную к источнику. Ключ, управляемый оператором, может находиться в /etc/apt/keyrings/, а запись источника называет ключ, которому разрешено удостоверять этот архив. Это уже, чем бросать тот же ключ в глобально доверенный набор, где он может ручаться за источники, которые вы никогда не хотели разрешать. Следуйте установленной версии APT и текущим инструкциям поставщика, а не смешивайте фрагменты из разных поколений руководств.

curl -fsSL https://repo.example.com/vpn-key.gpg -o /etc/apt/keyrings/vpn.gpg
echo "deb [signed-by=/etc/apt/keyrings/vpn.gpg] https://repo.example.com/debian stable main" > /etc/apt/sources.list.d/vpn.list

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

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

Закрепление источника — не список разрешённых пакетов

Ограничение ключа одним источником ограничивает то, какой архив он может удостоверять, а не то, какие пакеты этот архив может публиковать. Репозиторий может поставить гораздо больше, чем нужный вам VPN-клиент, и именно выбор кандидатов и приоритеты APT решают, какая подходящая версия победит. Просмотрите предлагаемую транзакцию до подтверждения, включая список зависимостей, потому что зависимости приходят из того же архива. Область ключа не может выразить «только этот пакет».

Если нужен более строгий контроль, выразите его как политику в отношении имён или версий пакетов и держите эту политику под управлением конфигурацией. Чтение транзакции занимает минуту; обнаружение неожиданного пакета полгода спустя занимает проверку.

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

Запишите полномочие и способ его удаления

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

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

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