RPM - изменение пакета после подписания

Question

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

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

Что я ищу - это трюк, позволяющий мне модифицировать файл, не нарушая подпись.

Вот что я пытался до сих пор:

1. «ведущая» часть пакета содержит зарезервированные байты, которые могут быть использованы, но очень ограничен в размерах и не масштабируется.
2. Добавление расширенных атрибутов файла - очень проста в использовании, но атрибуты исчезают при копировании файла (для сохранения атрибутов существуют специальные флажки, но мы не можем обеспечить их использование).
3. Мы подумали о том, чтобы вставить фиктивный заголовок в RPM и обмануть код RPM, чтобы не проверять его, но не знаете, как это сделать.
4. Подписание пакета ПОСЛЕ того, как была выполнена персонализация - также не масштабируема, потому что это означает, что нам нужно подписать пакет для каждого клиента, а не только один раз.

Обратите внимание, что я знаю, что подпись должна предотвращать изменение содержимого файла (он ведет себя так, как ожидалось). Тем не менее, я действительно не хочу изменять данные RPM , просто добавьте дополнительную информацию в файл.

Любые идеи?

Спасибо!

Answer 1

Если вы действительно ДОЛЖНЫ изменить * .rpm при сохранении существующих подписей, добавьте теги в заголовок подписи, предпочтительно с номерами тегов между десятичными ~ 275 и 999. Оба существующих сигнатурных текста (заголовок и заголовок + полезная нагрузка) не будут затронуты дополнительными тегами/данными в заголовке подписи.

Обратите внимание, что более поздние версии RPM были вынуждены явно перечислять теги и типы и данные, чтобы предотвратить обнаружение segfaults с помощью fuzzing. Но даже в этом случае есть тег дополнения (0x3fffffff из памяти), который может быть заполнен дополнительными данными. Опять же - iirc - последние версии rpm также подтверждают, что заполнение - все 0x00, поэтому предостережение emptor.

Между тем вы не описали, что такое «персонализация», и любые теги, добавленные в заголовок подписи, будут отброшены, когда пакет будет установлен. Также обратите внимание, что код для перезаписи заголовка подписи в * .rpm немного сложнее из-за заполнения, чтобы заголовок метаданных, следующий за заголовком подписи, выравнивался по 8 байт.

Я предлагаю вам обнаружить, что дополнительный файл, содержащий «персонализацию», является лучшим инженерным подходом. Искусство взлома знать, когда остановиться ;-)

Answer 2

5-й вариант заключается в создании пакета, который включает ваши изменения и зависит от подписанного пакета. Подписываете ли вы ваш пакет, конечно, зависит от того, как он распространяется.

Если пакет изменяет файлы в оригинальном RPM, вы можете работать вокруг этого (конфликтующего использования имен файлов), делая %pre и %preun скриптлетов переименовать исходные файлы в версию резервного копирования и добавление символической ссылки на ваши замены. Это мешает проверке исходного содержимого пакета, но ваши изменения должны быть чем-то, что вы можете проверить в каждом конкретном случае.

Answer 3

Подписание пакета ПОСЛЕ персонализация имеет место - также не масштабируется, потому что это означает, что мы должны подписать пакет для каждого клиента, а не только один раз.

Почему это не масштабируется? Просто потому, что rpmsign хочет, чтобы вы вводили кодовую фразу? Посмотрите на obs-sign https://en.opensuse.org/openSUSE:Build_Service_Signer (доступно в Suse, Fedora и Epel). Он способен автоматизировать подписание и все же сохранять его в безопасности.