Пакет не подписан линукс

Обновлено: 07.07.2024

В нашем дистрибутиве программы (состоящие, как правило, из нескольких файлов) распространяются объединенными в пакеты формата RPM (RedHat Packet Manager).

С помощью программы rpm можно легко устанавливать, модифицировать, удалять и создавать пакеты программного обеспечения, а также получать о них разнообразную информацию. Весь дистрибутив ALT Linux Master (кроме программы начальной установки) состоит из таких пакетов.

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

Далее приводятся возможные параметры. вставить насчет rpm4, db3, ^C, rm -f /var/lib/rpm/__* ---- mike, 02.22.2002, 18:58 ----

Установка пакета. Вы можете установить программу, используя опцию -i (опции -v и -h выставлены здесь для того, чтобы включить визуальное отображение процесса установки). Например, для того, чтобы установить klyx, наберите:

(настоящее имя зависит от версии программы на доступном носителе).

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

Удаление пакета. Если вы желаете удалить пакет из системы, внимательно введите:

то есть, например, для пакета klyx:

Если в процессе удаления пакета произойдет нарушение зависимостей, программа rpm сообщит об этом.

-qi используется для получения некоторой информации о ранее установленном пакете;

-qip используется для еще не установленных пакетов. В этом случае вы должны указать полный путь и имя пакета (например, /mnt/cdrom/Mandrake/RPMS/klyx-0.10.9-ipl6mdk.i586.rpm);

-ql используется для того, чтобы просмотреть список файлов пакета. Добавьте p, если пакет еще не был установлен;

-qa выдает список всех установленных пакетов (не нужно указывать имя пакета).

Для получения дополнительной информации наберите man rpm.

Обеспечение и поддержание целостности системы с помощью APT

История переиздания
Издание 0.2	23 May 2002
Рабочая версия

Введение

Для целей поддержания целостности и обеспечения возможности распространения программ в двоичном виде в первую очередь стали использоваться менеджеры пакетов (такие, как RPM в дистрибутивах RedHat Linux или dpkg в Debian GNU/Linux). Менеджеры пакетов давали возможность унифицировать и автоматизировать сборку двоичных пакетов и облегчали их установку, позволяя проверять наличие необходимых для работы устанавливаемой программы компонент подходящей версии непосредственно в момент установки. Однако менеджеры пакетов оказались неспособны предотвратить все возможные коллизии при установке или удалении программ, а тем более эффективно устранить нарушения целостности системы. Особенно сильно этот недостаток сказывается при обновлении систем из централизованного репозитория пакетов, в котором последние могут непрерывно обновляться, дробится на более мелкие и т.д. Этот недостаток и стимулировал создание систем управления программными пакетами и поддержания целостности системы.

Эти привлекательные возможности были долгое время доступны только пользователям Debian GNU/Linux, поскольку в APT поддерживалась только один менеджер пакетов, а именно применяемый в Debian GNU/Linux менеджер пакетов dpkg, несовместимый с используемой в ALTLinux RPM. Эта несовместимость заключается прежде всего в различии используемых форматов данных (хотя сущесвуют программы-конверторы), хотя имеютсяа и другие различия, обсуждение которых выходит за рамки изложения.

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

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

Задача контроля целостности и непротиворечивости установленного в системе ПО еще сложнее. Представим, что некие программы A и B требуют наличия в системе компоненты C версии 1.0. Обновление версии пакета A, требующее обновления компоненты C до новой, использующей новый интерфейс доступа, версии (скажем, до версии 2.0), влечет за собой обязательное обновление и программы B.

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

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

Использование APT

Система APT состоит из нескольких утилит. Главной и наиболее часто используемой является утилита управления пакетами apt-get: она автоматически определяет зависимости между пакетами и строго следит за их соблюдением при выполнении любой из следующих операций: установка, удаление или обновление пакетов.

apt-get позволяет устанавливать в систему пакеты, требующих для своей работы других, пока еще не установленных. В этом случае он определяет, какие из отсутствующих пакетов необходимо установить, и доустанавливает их, пользуясь всеми доступными репозиториями. Для того, чтобы apt-get мог использовать тот или иной репозиторий, информацию о нем необходимо поместить в файл /etc/apt/sources.list и выполнить команду

Эту команду необходимо также выполнять каждый раз, когда вы собираетесь работать с репозиторием после длительного перерыва, так как при поиске пакетов APT должен руководствоваться базой данных, отражающей актуальное состояние репозитория. Такая база данных создается заново каждый раз, когда в репозитории происходит изменение: добавление, удаление или переименование пакета. Для ускорения работы apt-get хранит локальную копию базы данных, которая через некоторое время может уже не соответствовать реальному состоянию репозитория.

В качестве источника пакетов можно использовать и компакт-диски дистрибутива, поскольку на каждом диске присутствует вся необходимая для APT информация о содержащихся на нем пакетах. Для этого необходимо использовать утилиту apt-cdrom с единственным параметром add:

Повторите этот процесс для всех CD в вашем наборе.

После этого в /etc/apt/sources.list появится запись о подключенном диске:

Если подключение к Internet отсутствует, то следует закомментировать те строчки в /etc/apt/sources.list, в которых говорится о ресурсах, доступных по Сети. Непосредственно после установки дистрибутива ALTLinux в /etc/apt/sources.list указаны несколько таких источников:

репозиторий обновлений в системе безопасности дистрибутива;

исходные тексты архивов, использовавшихся для сборки пакетов в репозитории Sisyphus .

Установка или обновление пакета

Установка пакета с помощью APT, выполняется командой

Команда apt-get install имя_пакета используется и для обновления уже установленного пакета или группы пакетов. В этом случае apt-get дополнительно проверяет, не обновилась ли версия пакета в репозитории по сравнению с установленным в системе. Если вы не знаете точное название пакета, для его поиска можно воспользоваться утилитой apt-cache, описанной ниже.

Пример 3.1. Установка пакета clanbomber командой apt-get install clanbomber приведет к следующему диалогу с APT:

Внимание

apt-get всегда спрашивает подтверждение выполнения операции установки и обновления, за исключением случая, когда реально требуется установить в систему (или обновить) только один пакет. Если вы не уверены в том, что результате выполнения операции система останется работоспособной, запустите apt-get с опцией -S, которая покажет отчет выполнения операции обновления, но реально обновление произведено не будет.

В случае обнаружения противоречий между установленными в системе пакетами, следует запустить команду apt-get -f install, и APT постарается разрешить найденные конфликты, предложив удалить или заменить конфликтующие пакеты. Любые действия в этом режиме обязательно требуют подтверждения со стороны пользователя.

Удаление установленного пакета

Для удаления пакета используется команда apt-get remove имя_пакета. Для того, чтобы не нарушать целостность системы, будут удалены и все пакеты, зависящие от удаляемого: если отсутствует необходимая для работы приложения библиотека, то само приложение становится бесполезным). В случае удаления пакета, который относится к базовым компонентам системы, apt-get потребует дополнительного подтверждения производимой операции с целью предотвратить возможную случайную ошибку.

Запрос на подтверждение операции удаления базовой компоненты системы выглядит следующим образом:

Обновление всех установленных пакетов

Для обновления всех установленных пакетов используется команда apt-get upgrade. Она позволяет обновить те и только те установленные пакеты, для которых в репозиториях, перечисленных в /etc/apt/sources.list, имеются новые версии; при этом из системы не будут удалены никакие другие пакеты. Этот способ полезен при работе со стабильными пакетами приложений, относительно которых известно, что они при смене версии изменяются несущественно.

В случае обновления всего дистрибутива APT проведет сравнение системы с репозиторием и удалит устаревшие пакеты, установит новые версии присутствующих в системе пакетов, а также отследит ситуации с переименованиями пакетов или изменения зависимостей между старыми и новыми версиями программ. Все, что потребуется поставить (или удалить) дополнительно к уже имеющемуся в системе, будет указано в отчете apt-get, которым APT предварит само обновление.

При работе с Sisyphus для обновления системы рекомендуется использовать командуapt-get dist-upgrade.

Поиск в репозитории

Для поиска нужного пакета можно воспользоваться утилитой apt-cache, которая позволяет искать не только по имени пакета, но и по его описанию.

Команда apt-cache search подстрока позволяет найти все пакеты, в именах или описании которых присутствует указанная подстрока. Например:

Для того, чтобы подробнее узнать о пакете, можно воспользоваться командой apt-cache show, которая покажет информацию о пакете из репозитория и в том числе:

Настройка APT

Настройка описаний репозиториев задается в файле /etc/apt/sources.list в следующем виде:

Например, при установке ALTLinux в /etc/apt/sources.list записываются следующие настройки:

Более подробное описание команд программы apt-get можно найти в справочной системе дистрибутива на страницах apt-get(8) и apt.conf(5).

Создание собственного репозитория

Вы можете создавать собственные репозитории и использовать их для обновления и/или установки собственных программ. Для этого необходимо создать структуру каталогов, подобную описанной выше. Вы можете выбирать из следующих компонентов (перечисляются по дереву выше):

архитектура, под которую собраны пакет (совпадает с таковой в имени бинарных RPM-пакетов)

название подсистемы. Этот уровень в дереве может отсутствовать (то есть, каталоги RPMS и base могут идти сразу следом за архитектурой)

каталог, в котором размещены бинарные пакеты

каталог, в котором размещены пакеты с исходными текстами программ

ссылка на каталог RPMS. При этом sisyphus заменяется на собственное название репозитория, например, local

служебный каталог, в котором размещается база данных APT

Из опций, список которых можно увидеть при запуске genbasedir без параметров, наиболее важной является опция --topdir, позволяющая указать путь к репозиторию. Все остальные параметры задаются относительно этого пути. Выглядит это следующим образом. Допустим, что наше дерево каталогов выглядит так:

Тогда строка запуска genbasedir будет выглядеть так:

Репозиторий MyDistro.security, хранящий пакеты с исправлениями ошибок в системе безопасности, имеет смысл подписывать PGP-ключом, чтобы при установке пакета можно было проверить аутентичность репозитория и хранящихся в нем пакетов. Для этого необходимо создать соответствующий PGP-ключ, используя программу GnuPG (gpg) и запомнить его отпечаток (fingerprint) на клиентских машинах в файле /etc/apt/vendors.list в формате:

Примером может служить ключ службы безопасности ALT Linux Team , которым подписаны пакеты репозитория Sisyphus и обновления безопасности для различных дистрибутивов ALTLinux :

Для того, чтобы APT проверял аутентичность подписи, необходимо указать, что соответствующий репозиторий подписан PGP-ключом в /etc/apt/sources.list:

Необходимо также сгенерировать информацию для APT в репозитории с указанием опции --sign команды genbasedir. Дополнительно, можно указать идентификатор ключа, если он отличается от ключа по умолчанию, используя опцию --uid=идентификатор. Значением этой опции является идентификатор ключа в том виде, как он передается программе GnuPG в опции --default-key:

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

Этичный хакинг и тестирование на проникновение, информационная безопасность

Решение ошибки «Следующие подписи неверные» в Kali Linux

При использовании команды apt, например, для обновления информации о пакетах, либо при установке нового пакета, вы можете столкнуться с ошибкой:

Если у вас используется английская локаль, то ошибка будет выглядеть так:

Если вы столкнулись с этой проблемой, то для её исправления выполните следующие команды:

Причина и описание проблемы

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

Для верификации пакетов в системе каждого пользователя должен иметься публичный ключ. В случае смены ключей для подписания пакетов, также необходимо поменять публичный ключ в системах пользователей. Сопроводители дистрибутива Kali Linux заранее знают, когда должны быть обновлены ключи, поэтому ещё до смены ключей новый публичный ключ добавляется в системы пользователей во время очередного обновления. Поэтому для пользователей смена ключей, обычно, проходит гладко и незаметно.

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

Двумя командами, которые приведены для решения проблемы, мы скачиваем публичный ключ с официального сайта Kali Linux и добавляем его в систему как доверенный.

Далее ещё больше теории о проверки подлинности пакетов.

Проверка подлинности пакета

Обновление системы – очень чувствительная операция, и мы действительно хотим, чтобы у нас устанавливались только официальные пакеты из хранилищ Kali. Если зеркало Kali, которое вы используете, было скомпрометировано, взломщик компьютера может попытаться добавить вредоносный код в другой законный пакет. Такой пакет, если он попадёт в вашу систему, может делать все действия, которые в него заложил взломщик, включая раскрытие паролей или конфиденциальной информации. Чтобы обойти этот риск, Kali обеспечивает защиту от несанкционированного доступа, чтобы на время установки гарантировать, что пакет действительно исходит от его официального сопровождающего и не был изменен третьей стороной.

Для осуществления подписи ПО, на машине были установлены следующие пакеты: bsign, binutils, gzip, lzma, bzip2, gnupg.

Подпись пакетов в Astra Linux SE 1.6

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

gpg --import secret_key.key

Для проверки правильности импорта:

Для подписывания пакетов может быть использован сценарий.

В сценарии необходимо указать

key_id="ID Вашего ключа"
pass_file="Абсолютный путь к файлу с парольной фразой"

Сценарий должен запускаться от имени пользователя root. В качестве первого аргумента должен быть указан полный путь до каталога, содержащего пакеты, которые необходимо подписать. В качестве второго аргумента должен быть указан каталог, в который будут помещаться подписанные пакеты.

sign-deb16.sh /root/pkg /root/pkg_sign

Если ПО было подписано ранее, ключами, сгенерированными для версий ОС 1.5 и ниже, обеспечить работу такого ПО в режиме ЗПС можно установив пакет astra-digsig-oldkeys

Открытые ключи необходимо размещать в директории /etc/digsig/keys/legacy/keys/

Подпись пакетов в ОС 1.4 и выше

Для подписывания пакетов может быть использован сценарий. Сценарий должен запускаться от имени пользователя root. В качестве первого аргумента должен быть указан полный путь до каталога, содержащего пакеты, которые необходимо подписать. В качестве второго аргумента должен быть указан каталог, в который будут помещаться подписанные пакеты.

Для корректной работы сценария в строке:

заменить 00000 на идентификатор ключа, с помощью которого необходимо подписать пакет, а вместо /root/key_password.txt - указать полный путь к файлу с паролем к ключу. Идентификатор ключа можно получить, используя команду:

Подписывание ПО в среде операционной системы специального назначения «Astra Linux Special Edition» версии 1.5 ключом, сгенерированным для более ранних версий

, где key_for_signing.key это название переданного Вам ключа.

Если на вашем IoT-шлюзе установлена операционная система с поддержкой SRM, каждый RPM-пакет, перед инсталляцией, нужно подписывать, даже если IMA-безопасность не используется. Из этого материала вы узнаете о том, как подписывать и устанавливать RPM-пакеты в операционных системах шлюзов с включенным и выключенным SRM.

То, о чём мы здесь расскажем, применимо к IoT-шлюзам Intel, основанным на процессорах Intel Atom, Intel Core и Intel Quark. Освоив это руководство, вы научитесь работать с RPM-пакетами. А именно, подписывать их, устанавливать, деинсталлировать. Так же мы рассмотрим сборку ОС для шлюзов и работу с ключами.

Ожидается, что читатель этого материала обладает следующими знаниями и навыками:

Исполнение команд Linux.
Создание, правка, исполнение скриптов.
Установка и настройка программного обеспечения для Linux
Использование эмулятора терминала, наподобие Putty, при наличии соединения между компьютерами по последовательному интерфейсу.

Так будут выделены команды, названия API, параметры, имена обычных и исполняемых файлов, пути в файловой системе.

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

А так выделены блоки текста, демонстрирующие реакцию системы на выполнение скрипта или исполнение команды, введённой с клавиатуры.

Для того, чтобы испытать на практике то, о чём пойдёт речь, у вас должен быть подготовленный к работе шлюз. На компьютере должна быть развёрнута среда разработки Wind River.

SRM в операционной системе шлюза

Рассмотрим, как собрать и установить на шлюзе операционную систему с включенной функцией безопасности (SRM). Когда безопасность включена, перед установкой RPM-пакетов на шлюз их нужно подписывать. Для начала модифицируем скрипт конфигурации операционной системы шлюза.

Включите в него это:

Найдите и удалите следующее:

wr-ima-appraise из выражения --without-layer=.
wr-mcafee из выражения --with-layer= .

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

Переносим образа ОС на флэш-диск

Скопируем собранный образ на загрузочный флэш-диск. Его ёмкость должна быть, как минимум, 4 Гб. При этом учитывайте, что при записи образа ОС все данные с диска будут удалены.

Вот, как выглядит выполнение вышеописанной последовательности действий.

Вывод списка устройств хранения данных, подключённых к компьютеру

На следующем шаге вам понадобится знать имя USB-диска в системе. В нашем случае это — /dev/sdb.

Команда для шлюзов с процессором Intel Atom:

Команда для шлюзов с процессором Intel Quark:

Устанавливаем ОС на шлюз

Теперь установим операционную систему на шлюз. Обратите внимание на то, что перед загрузкой шлюза с флэш-диска нужно внести соответствующие изменения в BIOS. Здесь, в разделе «Appendix: Setup BIOS Boot from USB», можно найти подробности об этом. Когда шлюз будет готов к загрузке с внешнего носителя, выполните следующие шаги:

Команда для шлюзов с процессором Intel Quark:

Собираем незащищённый RPM-пакет

Создадим проект, который включает в себя незащищённый RPM-пакет. Назовём его hello. Так как в этом пакете безопасность (SRM) отключена, его можно использовать для того, чтобы поэкспериментировать с подписями.

Следующие действия нужно выполнить на компьютере.

Команда для шлюзов с процессором Intel Atom:

Команда для шлюзов с процессором Intel Quark:

Пакет будет собран и сохранён.

Копии пакета и правильный ключ

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

Следующие действия нужно выполнить на компьютере.

Если всё сделано так, как нужно, она должна выдать следующий список файлов:
[hello file].rpm
owner-cert.pem
owner-private.pem
vendor-cert.pem
vendor-private.pem

В итоге, на данном этапе у вас должно получиться следующее:

Создаём ключи

В разделе «SRM в операционной системе шлюза» были созданы ключи, которые подходят для подписывания RPM-пакетов. В предыдущем разделе мы скопировали эти ключи и пакет hello в папку $HOME/project_nonsrm/rpmtest/goodkeys .

Сейчас создадим собственный набор ключей, которые поместим в папку badkeys. И, хотя эти ключи являются вполне нормальными, они не подходят для подписывания пакета, поэтому мы считаем их «неправильными». Цель создания этих ключей заключается в том, чтобы вы увидели, что произойдёт, если воспользоваться неподходящими ключами для подписывания пакета.

Следующие действия нужно выполнить на компьютере.

badowner-cert.pem
badowner-private.pem
badvendor-cert.pem
badvendor-private.pem
[hello file].rpm

Вот, что теперь у нас есть:

— Пакет hello и ключи, подходящие для его подписывания в папке goodkeys .
— Пакет hello и неподходящие ключи в папке badkeys .
— Пакет hello в папке notsigned без каких-либо ключей.

Подписываем RPM-пакет

Пакеты подписывают закрытым ключом поставщика, и, когда пакет устанавливают на шлюз, вместе с ними устанавливается и ключ vendor-cert.pem . Он используется для проверки подписи. Сейчас мы, с помощью команды SST sign-rpm , подпишем пакеты, расположенные в папках с неподходящими и подходящими ключами.

— Пакет hello, подписанный подходящим ключом в папке goodkeys .
— Пакет hello, подписанный неподходящим ключом в папке badkeys .
— Неподписанный пакет hello в папке notsigned .

Поместите все три папки в tar-архив и скопируйте его на USB-диск. В данном примере USB-диск смонтирован как /media/rpmflash . Отредактируйте команды, приведённые ниже, в соответствии с тем, как диск отображается в вашей системе.

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

Устанавливаем пакеты

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

Неподписанный пакет.
Пакет, подписанный неправильным ключом.
Пакет, подписанный правильным ключом.

MD5 Code:e91148db3dd3a5e0bdb76ea5a8fa8e34
Can not find the right certificate for RPM [hello file].rpm

Деинсталлируем пакеты

Выше мы успешно установили правильно подписанный пакет. Теперь удалим его.

Эта команда выведет имя пакета, что указывает на то, что он установлен.

Сертификаты: получаем сведения, удаляем и устанавливаем

Рассмотрим методы работы с сертификатами на шлюзе.

Она сообщит сертификате, который был скопирован в папку $HOME/project_nosrm/rpmtest/goodkeys в разделе «Копии пакета и правильный ключ».
vendor-cert.pem

Так как сертификат удалён, в результате выполнения команды ничего выведено не будет.

Читайте также: