от Beco(1-04-2006)

рейтинг (20)   [ добре ]  [ зле ]

Printer Friendly Вариант за отпечатване

OpenPGP интеграция в RPM

Copyright ©2006 Веселин Колев, Софийски Университет "Св. Климент Охридски"

Лиценз: CC Attribution-ShareAlike


  1. Въведение.
  2. Поставяне на OpenPGP сертификат в базата на RPM.
  3. Представяне и преглед на инсталираните OpenPGP сертификати в базата на RPM.
  4. Преглед на съдържанието на инсталираните OpenPGP сертификати в базата на RPM.
  5. Изтриване на инсталиран OpenPGP сертификат от базата на RPM.
  6. Проверка на електронния подпис върху файл, съдържащ RPM пакет.
  7. Проверка на електронния подпис върху инсталиран RPM пакет.

1. Въведение.

RPM[1] е пакетна система, в която всеки пакет подлежи на интеграция в рамките на сертификатен модел за удостоверяване. За удостоверителен модел е избран OpenPGP. Когато един RPM пакетен файл бъде създаден, съдържанието му се подписва така, че електронния подпис се поставя вътре в създадения RPM файл (това отличава пакетната система RPM от пакетни системи, при които електронния подпис се съхранява във файл извън пакета). Така електронният подпис следва пакетния файл навсякъде и служи за идентификация на лицето или организацията, която е произвела пакета. Възможно е електронният подпис да бъде извършен и от този, който предоставя/дистрибутира пакета (благодарение на възможността за реподписване на пакета), а не от създателя му (при реподписването, електронния подпис на създателя на пакета може да бъде заменен с електронния подпис на дистрибутора).

Когато един RPM пакет трябва да бъде инсталиран, е наложително да бъде проверен електронния подпис интегриран в него. Създаването на таква практика силно намалява възможността за подмяна ("пробутване" на опасен пакет, който примерно може да отвори дупка в сигурността на системата, да унищожи файлове, да използва несанкционирано ресурси и т.н). Разбира се, инсталиращият пакета трябва да притежава копие от OpenPGP сертификата на лицето и организацията, които са подписали пакета. От гледна точка на сертификатния модел OpenPGP, не е достатъчно проверяващия електронния подпис просто да притежава копие от сертификата. Той трябва да е убеден в неговата автентичност. Следователно трябва да съществува канал за проверка на автентичността - примерно представител на дистрибутура гарантира за сертификата или пък да се ползва схемата на онаследено доверие в рамките на Web Of Trust (тази схема няма да бъде коментирана тук).

Сертификатното хранилище на базата на RPM няма нищо общо със сертификатното харанилище на други приложения, по-специално GNUPG. Проверката в рамките на Web Of Trust се прави в рамките на GNUPG и неговото сертификатно хранилище и чак след това удостоверения сертификат се прехвърля в RPM базата с OpenPGP сертификати.

Настоящата статия има за цел да покаже възможностите за интеграцията на сертификатния модел OpenPGP в пакетната система RPM. По-задълбочени познания за пакетната система RPM могат да се получат от различните документации на тази тема, като повечето от тях са свободно достъпни в Интернет. Към настоящият момент най-пълното ръководствто за потребители по използване на пакетната система RPM е създадено в рамките на проекта по документация на дистрибуцията Fedora Core[2].

Статията е фокусирана върху работата с пакетната система RPM в рамките на дистрибуциите Fedora Core и Red Hat Enterprise Linux.

Авторът не носи отговорност за причинени щети, вследствие на използване на описаните тук действия и техники.

2. Поставяне на OpenPGP сертификат в базата на RPM.

За да се постави един OpenPGP сертификат в RPM базата, той трябва да е наличен в текстов файл (ASCII) във формат Base64. Спрямо значимостта си към RPM базата, OpenPGP сертификатите се разделят на два типа (чисто условно):такива, които удостоверяват автентичността на пакетите в хранилищата с пакети на дистрибуцията, поддържани от дистрибутора и такива, които удостоверяват автентичността на външни за дистрибуцията пакети (например от хранилища, които не са поддържани от дистрибутора на дистрибуцията). Всички OpenPGP сертификати, в рамките на RPM базата, се инсталират в една централен контейнер - сертификатно хранилище. В дистрибуциите Fedora Core и Red Hat Enterprise Linux (и дериватите), сертификатното хранилище на RPM базата физически се намира във файла /var/lib/rpm/Pubkeys. Това е бинарен файл във формат BerkeleyDB.

  • OpenPGP сертификати удостоверяващи автентичността на съдържанието на пакетите в хранилищата на дистрибуцията

Това са сертификатите на производителя на дистрибуцията. От критично значение е тяхната автентичност да бъде установена еднозначно, доколкото тези сертификати се използват за проверка на най-важните пакети за системата (kernel, glibc, rpm и др). Обикновено те се инсталират със самата дистрибуция като ASCII файлове във файловото дърво на системата, без обаче да се инсталират в RPM базата. В зависимост от дистрибуцията (или дори версията на дистрибуцията), тяхното местоположение може да е различно:

  • Fedora Core 4 и Fedora Core 5

До Fedora Core 4 сертификатите на производителя на дистрибуцията се съхраняваха само в директорията /usr/share/rhn/. Във версия четири на Fedora Core, мястото за разполагане на OpenPGP сертификатите на дистрибуцията е вече директорията /etc/pki/rpm-gpg/. Ето едно нейно примерно съдържание:

-rw-r--r-- 1 root root 1910 Jun 3 2005 RPM-GPG-KEY
-rw-r--r-- 1 root root 1706 Jun 3 2005 RPM-GPG-KEY-beta
-rw-r--r-- 1 root root 1519 Jun 3 2005 RPM-GPG-KEY-fedora
-rw-r--r-- 1 root root 2043 Jun 3 2005 RPM-GPG-KEY-fedora-extras
-rw-r--r-- 1 root root 1105 Jun 3 2005 RPM-GPG-KEY-fedora-rawhide
-rw-r--r-- 1 root root 1076 Jun 3 2005 RPM-GPG-KEY-fedora-test
-rw-r--r-- 1 root root 1232 Jun 3 2005 RPM-GPG-KEY-rawhide

Сертификатите се поставят там при инсталацията на дистрибуцията от пакета fedora-release.

  • Red Hat Enterprise Linux 4

В рамките на тази дистрибуция, OpenPGP сертификатите на производителя й се намират в директория /usr/share/rhn/. Инсталират се в дистрибуцията при инсталирането на пакета up2date. Примерното съдържание на директорията /usr/share/rhn/ е от вида:

drwxr-xr-x 2 root root 4096 Mar 8 19:04 actions
-rw-r--r-- 1 root root 1489 Mar 20 2002 BETA-RPM-GPG-KEY
-rwxr-xr-x 1 root root 0 Aug 9 2001 __init__.py
-rw-r--r-- 1 root root 106 Mar 7 20:45 __init__.pyc
drwxr-xr-x 2 root root 4096 Mar 8 19:32 rhn_applet
-rw-r--r-- 1 root root 11381 Aug 29 2003 RHNS-CA-CERT
-rw-r--r-- 1 root root 1913 Aug 30 2002 RPM-GPG-KEY
-rw-r--r-- 1 root root 1519 Oct 29 2003 RPM-GPG-KEY-fedora
-rw-r--r-- 1 root root 1076 Oct 29 2003 RPM-GPG-KEY-fedora-test
drwxr-xr-x 3 root root 4096 Mar 8 19:04 up2date_client

Най-важният OpenPGP сертификат в тази директория се намира във файла RPM-GPG-KEY. Чрез него се проверява автентичността на всички RPM пакети (базови и тези постъпили като актуализации).

Въпреки, че всички тези OpenPGP сертификати са поставени в упоменатите директории от RPM пакет в състава на дистрибуцията, трябва да се реши въпроса относно тяхната автентичност и тя трябва да бъде установена еднозначно. Установяването на автентичността излиза извън пределите на RPM. За целта на удостоверяването се използват външни модели и инструменти. Един подходящ начин е да се използва модела на Web Of Trust. От друга страна, ако е била потвърдена автентичността на инсталационния носител, то с голяма вероятност може да се твърди, че пакета, от който са инсталирани OpenPGP сертификатите в дистрибуцията не е подменян злоумишлено и инсталираните от него сертификати са автентични.

  • OpenPGP сертификати удостоверяващи автентичността на съдържанието на пакетите в хранилища външни за дистрибуцията

Най-често копия на тези OpenPGP сертификати могат да бъдат намерени във файл, който се намира във файлово дърво на съответното хранилище. Това, че даден сертификат се намира във файловото дърво на хранилището, още не го прави автентичен. За да се провери автентничността му трябва да се използва модела Web Of Trust.

В някои пакетни хранилища няма файл, който да съдържа OpenPGP сертификата на производителя/дистрибутора на пакетите. В този случай OpenPGP сертификата може да бъде намерен върху някой от сървърите за ключове в Интернет. След това отново се прилага модела Web Of Trust за установяване на автентичността.

Един пример за извличането на OpenPGP сертификат от сървър за ключове (сертификати) и записването му в ASCII файл, може да се даде чрез следната поредица командни редове:

$ gpg --keyserver pgp.mit.edu --search dag@wieers.com
gpg: searching for "dag@wieers.com" from HKP server pgp.mit.edu
Keys 1-3 of 3 for "dag@wieers.com"
(1) Dag Wieers (Dag Apt Repository v1.0)
1024 bit DSA key 6B8D79E6, created 2003-08-23
(2) Dag Wieers
1024 bit DSA key A838A2DA, created 1997-06-21
(3) Dag Wieers
512 bit RSA key 51BFC045, created 1997-03-15
Enter number(s), N)ext, or Q)uit > 1
gpg: key 6B8D79E6: public key "Dag Wieers (Dag Apt Repository v1.0) " imported
gpg: Total number processed: 1
gpg: imported: 1

$ gpg -a --export 6B8D79E6 > RPM-DAG-GPG

По този начин във файла RPM-GPG-DAG ще се намира OpenPGP сертификата, с който са подписани пакетите в съответното хранилище. Преди обаче да се използва, този сертификат трябва да се провери като автентичност в рамките на Web Of Trust или друг механизъм за удостоверяване на автентичността.

Поставянето на сертификатите в базата на RPM може да стане по два начина. Единият начин включва използването на инструмента rpm в команден ред, а другия е свързан с използването на yum.

  • поставяне на OpenPGP сертификат в базата на RPM чрез инструмента rpm

Това е най-удобният начин за поставяне на сертификатите в базата на RPM и може да се представи нагледно чрез следния пример (изпълнен от root):

# rpm --import /usr/share/rhn/RPM-GPG-KEY

След изпълнение на този команден ред, OpenPGP сертификатите от файла /usr/share/rhn/RPM-GPG-KEY ще бъдат поставени в базата на RPM. Вместо пълният път до файла с OpenPGP сертификата, може да се използва и протокол за файлов пренос, например FTP или HTTP с указване на пътя до файла върху отдалечен файлов сървър. Това обаче не се препоръчва, освен в случаите, в които преносната среда и източника на файла със сертификата са надеждно защитени и удостоверени. При указване на такъв пренос се използва указателн за проткола, например:

# rpm --import ftp://storage.server.tld/RPM-GPG-KEY

или

# rpm --import http://storage.server.tld/RPM-GPG-KEY

Нужно е да се има предвид, че при мрежови транспорт има и допълнителен риск, доколкото файлът се изтегля с права на root. За това този начин на поставяне на OpenPGP сертификат в базата на RPM трябва да се избягва и да се използва само в краен случай. Правилният начин е първо да се свали файла със сертификата върху локалната файлова система като процесът на изтегляне се иницира от непривилигерован потребител. След това се прави проверка на файла, дали наистина съдържа OpenPGP сертификат (може да се използва инструмента gpg) и чак тогава с правата на root и инструмента rpm, сертификата се импортира в базата на RPM.

  • поставяне на OpenPGP сертификат в базата на RPM чрез инструмента yum

В този случай се указва пътя до файла съдържащ OpenPGP сертификата (път до файла в локалната файлова система или върху отдалечен файлов сървър) на отделен ред при дефиниране на хранилище (добре е OpenPGP сертификатите в такъв случай да се отнасят към съответното хранилище). Ето примерен запис:

[extras]
name=Fedora Extras $releasever - $basearch
#baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/$releasever/$basearch/
mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-extras-$releasever
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras
gpgcheck=1

В този случай OpenPGP сертификата, с който се проверява автентичността на пакетите в хранилището с име extras, се съдържа във файла указан след указателя gpgkey (в конкретния случай това е файла /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras). При първото използване на това хранилище, ако OpenPGP сертификата, посочен във файла по-горе, не е наличен в RPM базата, ще бъде изведено диалогово меню, в което администратора трябва да избере да импортира или не в базата този сертификат.

3. Представяне и преглед на инсталираните OpenPGP сертификати в базата на RPM.

Всеки сертификат се представя в RPM базата като пакет. Следователно може да бъде търсен като такъв с наличните за целта инструменти. Всички OpenPGP сертификати в RPM базата може да се разглеждат като много едновременно налични версии на един и същи пакет с име gpg-pubkey. Версиите на пакетите gpg-pubkey се опрделят на база шестнадесетичния идентификатор на публичния ключ в основата на OpenPGP сертификата. Форматът на версията съдържа два шестнадесетични числа, разделени с тире. Идентификаторът на OpenPGP сертификата е първото число. Например във версията на пакета

gpg-pubkey-db42a60e-37ea5438

шестнадесетичното число db42a60e е идентификатора на публичния ключ в основата на OpenPGP сертификата, а 37ea5438 е хеш на датата на създаване на двойката "частен-публичен ключ". Идентификаторът на публичния ключ се използва за идентификация на даден сертификат, например в GNUPG:

$ gpg --list-keys db42a60e
pub 1024D/DB42A60E 1999-09-23 Red Hat, Inc
sub 2048g/961630A2 1999-09-23

  • преглед на инсталираните OpenPGP сертификати чрез инструмента rpm

За да бъде представен списък с инсталираните OpenPGP сертификати в базата на RPM, трябва да се извърши операция от вида:

$ rpm -q gpg-pubkey

Изходът от тази операция има вид подобен на следния:

gpg-pubkey-db42a60e-37ea5438
gpg-pubkey-4f2a6fd2-3f9d9d3b
gpg-pubkey-30c9ecf8-3f9da3f7
gpg-pubkey-7ad14380-43395f47
gpg-pubkey-6b8d79e6-3f49313d
gpg-pubkey-66534c2b-402ad7ae

  • преглед на инсталираните OpenPGP сертификати чрез инструмента yum

За целта може да се използва команден ред от вида:

$ yum list gpg-pubkey

изпълнението на който води до резултат от типа на

Setting up repositories
Reading repository metadata in from local files
Installed Packages
gpg-pubkey.None 4f2a6fd2-3f9d9d3b installed
gpg-pubkey.None 6b8d79e6-3f49313d installed
gpg-pubkey.None db42a60e-37ea5438 installed
gpg-pubkey.None 30c9ecf8-3f9da3f7 installed
gpg-pubkey.None 66534c2b-402ad7ae installed
gpg-pubkey.None 7ad14380-43395f47 installed

4. Преглед на съдържанието на инсталираните OpenPGP сертификати в базата на RPM.

Прегледът на съдържанието на инсталираните OpenPGP пакети в базата на RPM може да стане чрез инструментите rpm и yum.

  • преглед на съдържанието на инсталиран OpenPGP сертификат чрез инструмента rpm

Прегледът на съдържанието на инсталиран в базата на RPM OpenPGP сертификат чрез инструмента rpm, следва следната схема. Първо се избира сертификата като име на пакет и версия, както бе описано по-горе. След като изборът е направен, се изпълнява команден ред подобен на следния:

$ rpm -q --info gpg-pubkey-4f2a6fd2-3f9d9d3b

който води до резултата

Name : gpg-pubkey Relocations: (not relocatable)
Version : 4f2a6fd2 Vendor: (none)
Release : 3f9d9d3b Build Date: Tue 10 Jan 2006 12:46:44 PM EET
Install Date: Tue 10 Jan 2006 12:46:44 PM EET Build Host: localhost
Group : Public Keys Source RPM: (none)
Size : 0 License: pubkey
Signature : (none)
Summary : gpg(Fedora Project )
Description :
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: rpm-4.3.3 (beecrypt-3.0.0)

mQGiBD+dnTsRBACwnlz4AhctOLlVBAsq+RaU82nb5P3bD1YJJpsAce1Ckd2sBUOJD11NUCqH
8c7EctOquOZ5zTcWxHiWWbLyKQwUw2SUvnWa5SSbi8kI8q9MTPsPvhwtgMrQMLenMO+nsrxr
SaG6XcD+ssfJNxC7NQVCQAj3pvvg9rKi3ygsM7CXHwCghgsqX6TOr55HE90DbEsoq3b/jjsD
/i8aIZ6urUgrpAkQslcakXdJLKgSdwjRUgVZgvYZb7kAx1iPq0t/AhB3NJw3zW4AAKJohGg3
xj5K4V8PJEZrSIpoRYlF43Kqlfu2p5ghWT89SP4YAlWPeTqf0+dTYUYz3b144k2ZFOdRuXIR
xunoYNAUr9oMrxBXbJ/eY+0UQX3pBACYzKizyY4JJgd0zFJmNkcdK9nzcm+btYFnYQo33w5G
SE686UNr+9yiXt9tmPRvNEbj3u+xoAX8B/5k3aZ5NbUhV64/VcKlUdRIxNlFCG7I9KgxeHWA
Ywi7yqOGXM3T/v6o7GLdQEB0ChFqS7kUlqmwLV+C3QhlrFe/Cuk26i+Q6rQiRmVkb3JhIFBy
b2plY3QgPGZlZG9yYUByZWRoYXQuY29tPohbBBMRAgAbBQI/nZ07BgsJCAcDAgMVAgMDFgIB
Ah4BAheAAAoJELRCadBPKm/S2PAAnRTlhorITphab+oxAHtbxZF9BVyDAJ9WOVaZUG53IWWI
AXOGv3j/cmr3lohGBBMRAgAGBQI/nZ22AAoJECGRgM3bQqYOR5QAoIp1G+omVktq/snxpmz5
UeHjlSYjAKCRr/ea/L7S7ZTxB18cf1TYfad1x4hGBBARAgAGBQI/ntjgAAoJECnVuiSN9W0F
USUAoJnrone4J0o1HMkRz+6g9KVuO2FyAJ0XyebOzVmI9U5OyOfnNmYV0wnQcrkBDQQ/nZ08
EAQAugOfLWJbKwMA9vg2mJU594TZU0HRJkx/fqYhx0YxWWRpzplrEyvcDXuYcWi1Hwh0tD86
T4fR5GV6joWiWClzD+Hwhhb6gcSdeSGlGLlZAvWYtFSHWiv+3LaI9w8Vtczl99Bh2WiMDNDD
Gw0RQg6ZaftldLSe4j1pffpFGQ8SuisAAwUEAKVxqLT7fC5xQ6oclcZ+PhoDlePQ1BiTS7tu
GM07bFF4nNvY91LL7S31pooz3XbGSWP8jxzSv1Fw35YhSmWGOBOEXluqMbVQGJJ5m8fqJOjC
0imbfeWgr/T7zLrJeiljDxvX+6TyawyWQngF6v1Hq6FRV0O0bOp9Npt5zqCbDGs/iEYEGBEC
AAYFAj+dnTwACgkQtEJp0E8qb9L//gCcDVYnDegNCOxDn1sedDwxw+0h8OcAn1CZHof15Qqx
nTwEnvwF2QeOI5dn
=mJAx
-----END PGP PUBLIC KEY BLOCK-----

В този резултат се вижда използването на същите полета, каквито се използват за всички пакети инсталирани в базата на RPM. Изключение прави само информативната част (info). В нея чрез библиотеката beecrypt се извежда в Base64 формат OpenPGP сертификата. Така блокът директно може да се копира във файла и да се използва за повторно импортиране в RPM база или в хранилището на GNUPG, PGP и др.

  • преглед на съдържанието на инсталиран OpenPGP сертификат чрез инструмента yum

Прегледът на съдържанието на инсталиран в базата на RPM OpenPGP сертификат с инструмента yum става след като предварително се избере сертификат с определена версия. След това се изпълнява команден ред от типа:

$ yum info gpg-pubkey-4f2a6fd2-3f9d9d3b

Резултатът изглежда по следния начин:

Setting up repositories
Reading repository metadata in from local files
Installed Packages
Name : gpg-pubkey
Arch : None
Version: 4f2a6fd2
Release: 3f9d9d3b
Size : 0.0
Repo : installed
Summary: gpg(Fedora Project )

Description:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: rpm-4.3.3 (beecrypt-3.0.0)

mQGiBD+dnTsRBACwnlz4AhctOLlVBAsq+RaU82nb5P3bD1YJJpsAce1Ckd2sBUOJD11NUCqH
8c7EctOquOZ5zTcWxHiWWbLyKQwUw2SUvnWa5SSbi8kI8q9MTPsPvhwtgMrQMLenMO+nsrxr
SaG6XcD+ssfJNxC7NQVCQAj3pvvg9rKi3ygsM7CXHwCghgsqX6TOr55HE90DbEsoq3b/jjsD
/i8aIZ6urUgrpAkQslcakXdJLKgSdwjRUgVZgvYZb7kAx1iPq0t/AhB3NJw3zW4AAKJohGg3
xj5K4V8PJEZrSIpoRYlF43Kqlfu2p5ghWT89SP4YAlWPeTqf0+dTYUYz3b144k2ZFOdRuXIR
xunoYNAUr9oMrxBXbJ/eY+0UQX3pBACYzKizyY4JJgd0zFJmNkcdK9nzcm+btYFnYQo33w5G
SE686UNr+9yiXt9tmPRvNEbj3u+xoAX8B/5k3aZ5NbUhV64/VcKlUdRIxNlFCG7I9KgxeHWA
Ywi7yqOGXM3T/v6o7GLdQEB0ChFqS7kUlqmwLV+C3QhlrFe/Cuk26i+Q6rQiRmVkb3JhIFBy
b2plY3QgPGZlZG9yYUByZWRoYXQuY29tPohbBBMRAgAbBQI/nZ07BgsJCAcDAgMVAgMDFgIB
Ah4BAheAAAoJELRCadBPKm/S2PAAnRTlhorITphab+oxAHtbxZF9BVyDAJ9WOVaZUG53IWWI
AXOGv3j/cmr3lohGBBMRAgAGBQI/nZ22AAoJECGRgM3bQqYOR5QAoIp1G+omVktq/snxpmz5
UeHjlSYjAKCRr/ea/L7S7ZTxB18cf1TYfad1x4hGBBARAgAGBQI/ntjgAAoJECnVuiSN9W0F
USUAoJnrone4J0o1HMkRz+6g9KVuO2FyAJ0XyebOzVmI9U5OyOfnNmYV0wnQcrkBDQQ/nZ08
EAQAugOfLWJbKwMA9vg2mJU594TZU0HRJkx/fqYhx0YxWWRpzplrEyvcDXuYcWi1Hwh0tD86
T4fR5GV6joWiWClzD+Hwhhb6gcSdeSGlGLlZAvWYtFSHWiv+3LaI9w8Vtczl99Bh2WiMDNDD
Gw0RQg6ZaftldLSe4j1pffpFGQ8SuisAAwUEAKVxqLT7fC5xQ6oclcZ+PhoDlePQ1BiTS7tu
GM07bFF4nNvY91LL7S31pooz3XbGSWP8jxzSv1Fw35YhSmWGOBOEXluqMbVQGJJ5m8fqJOjC
0imbfeWgr/T7zLrJeiljDxvX+6TyawyWQngF6v1Hq6FRV0O0bOp9Npt5zqCbDGs/iEYEGBEC
AAYFAj+dnTwACgkQtEJp0E8qb9L//gCcDVYnDegNCOxDn1sedDwxw+0h8OcAn1CZHof15Qqx
nTwEnvwF2QeOI5dn
=mJAx
-----END PGP PUBLIC KEY BLOCK-----

И тук, както и при изхода получен чрез инструмента rpm, резултатът за описателната частта на пакета съдържа Base64 представянето на OpenPGP сертификата в блок, който може да бъде използван за последващи поставяния в хранилище на RPM или използването му в хранилището на програми като GNUPG, PGP и др.

5. Изтриване на инсталиран OpenPGP сертификат от базата на RPM.

Изтриването на един OpenPGP сертификат от базата на RPM може да се наложи в случайте, когато този сертификат няма да бъде използван повече или е компрометиран по някакъв начин. Пакетната система RPM чрез своя инструментариум не може да следи състоянието на даден OpenPGP сертификат. Подобно следене на състоянието на един OpenPGP сертификат може да стане например чрез периодична проверка за наличието на отменящи сертификати към дадения OpenPGP сертификат, които да укажат на неготово компрометиране. Като инструмент за реализация на този процес може да бъде използван gpg.

Както процесът по поставяне, така и този по изтриване на OpenPGP сертификат, може да реализира чрез използване на инструментите rpm и yum.

  • изтриване на инсталиран OpenPGP сертификат чрез инструмента rpm

Винаги трябва да се уточнява версията на пакета, чрез която е представен в RPM базата OpenPGP сертификата, който трябва да бъде изтрит. След като версията е уточнена, може да се пристъпи към изтриването му с помощта на команден ред със следната структура:

# rpm -e gpg-pubkey-4f2a6fd2-3f9d9d3b

  • изтриване на инсталиран OpenPGP сертификат чрез инструмента yum

Винаги трябва да се уточнява версията на пакета, чрез която е представен в RPM базата OpenPGP сертификата, който трябва да бъде изтрит. След като версията е уточнена, може да се пристъпи към изтриването му с помощта на команден ред от вида:

# yum remove gpg-pubkey-4f2a6fd2-3f9d9d3b

Като междинен разултат ще бъде представена информация за пакета, който подлежи на изтриване и диалог за потвърждение на операцията:

Setting up Remove Process
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package gpg-pubkey.None 0:4f2a6fd2-3f9d9d3b set to be erased
--> Running transaction check

Dependencies Resolved

=============================================================================
Package Arch Version Repository Size
=============================================================================
Removing:
gpg-pubkey None 4f2a6fd2-3f9d9d3b installed 0.0

Transaction Summary
=============================================================================
Install 0 Package(s)
Update 0 Package(s)
Remove 1 Package(s)
Total download size: 0
Is this ok [y/N]:

След потвърждаване на операцията (чрез "y") следва изтриване на пакета, т.е. на OpenPGP сертификата от базата на RPM.

6. Проверка на електронния подпис върху файл, съдържащ RPM пакет.

Преди да бъде инсталиран в системата, всеки RPM пакет представлява файл с разширение rpm. Всеки такъв файл може да бъде проверен от гледна точка на автентичност, като бъде проверен електронния подпис, който е извършен върху съдържанието (което пък се намира под формата на CPIO архив вътре в самия RPM файл).

За извършването на проверката е нужно да се разполага с OpenPGP сертификата на лицето или организацията, подписали пакета. Този сертификат трябва да е инсталиран в RPM базата. Преди всичко няма как в 100% от случаите от напред да се знае с какъв OpenPGP сертификат да се провери достоверността на съдържанието на RPM файла. Това може да се установи само опитно, след проверка. Ако в хода на проверката се установи, че OpenPGP сертификата, чрез който трябва да се провери електронния подпис върху съдържанието на RPM файла, не е наличен в RPM базата, то той трябва да бъде поставен там. След това проверката трябва да бъде извършена отново.

Ето и как се извършва проверката в команден ред чрез инструмента rpm в различни нива на подробност в резултата от проверката:

  • първо ниво на подробност

Това ниво на подробност на резултата от проверката се реализира чрез използването само на опцията "--checksig". Ето пример:

$ rpm --checksig stunnel-4.05-3.i386.rpm

Резултатът от изпълнението на горния команден ред има вид подобен на

stunnel-4.05-3.i386.rpm: (sha1) dsa sha1 md5 gpg OK

Това ниво на подробност само съобщава общия резултат от проверката, без да информира заявителя на проверката по-подробно. Статус съобщението "OK" е индикатор за положителна проверка на електронния подпис върху съдържанието на RPM пакета. Ако статусът не е "OK", трябва да се премине на по-високо ниво на подробност и там да се види къде точно е проблема (примерно OpenPGP сертификата, с който трябва да се извърши проверката на електронния подпис не е наличен в базата на RPM и т.н).

  • второ ниво на подробност

Второто ниво на подробност се реализира чрез използването на комбинация от опции "-v" и "--checksig" на инструмента rpm. Примерен команден ред, който показва реализация на това ниво на подробност при проверката на електронния подпис върху съдържанието на RPM файла, е следния:

$ rpm -v --checksig stunnel-4.05-3.i386.rpm

Резултатът от проверката има вида:

stunnel-4.05-3.i386.rpm:
Header V3 DSA signature: OK, key ID 7ad14380
Header SHA1 digest: OK (29ae0d7847ec4efb29da645528727a66ceab0d7c)
MD5 digest: OK (806296bc49590670bf40d2d162612b47)

V3 DSA signature: OK, key ID 7ad14380

В този резултат е включен флаг за всеки етап на проверката (имащ при успешна проверка стойност "OK"). Също така тук се показват стойностите на съответните суми и шестнадесетичния идентификатор на OpenPGP сертификата, с който се извършва проверката на електронния подпис.

  • трето ниво на подробност

За това ниво на подробност се използват опциите "-vv" и "--checksig". Това е най-високото ниво на подробност, което освен информацията, налична във второ ниво на подробност, дава и статуса на операциите по извеждането на информацията от самата база данни. За получаването на такова ниво на подоробност, може да се използва команден ред от вида:

$ rpm -vv --checksig stunnel-4.05-3.i386.rpm

След изпълнението му, се получава резултат подобен на следния:

D: Expected size: 119200 = lead(96)+sigs(344)+pad(0)+data(118760)
D: Actual size: 119200
D: opening db index /var/lib/rpm/Packages rdonly mode=0x0
D: locked db index /var/lib/rpm/Packages
D: opening db index /var/lib/rpm/Pubkeys rdonly mode=0x0
D: read h# 843 Header sanity check: OK
D: ========== DSA pubkey id 56d964ae7ad14380
stunnel-4.05-3.i386.rpm:
Header V3 DSA signature: OK, key ID 7ad14380
Header SHA1 digest: OK (29ae0d7847ec4efb29da645528727a66ceab0d7c)
MD5 digest: OK (806296bc49590670bf40d2d162612b47)
V3 DSA signature: OK, key ID 7ad14380
D: closed db index /var/lib/rpm/Pubkeys
D: closed db index /var/lib/rpm/Packages

7. Проверка на електронния подпис върху инсталиран RPM пакет.

Тази проверка засяга всички инсталирани файлове в рамките на даден пакет. Това значи, че в хода на проверката може да се установи дали даден файл от даден пакет е променян, липсва или е повреден. Цялата информация, необходима за проверката, се намира в RPM базата. Самата проверка се извършва с инструмента rpm в три нива на подробност. Изходът от операцията за проверка на целостта и автентичността на файловете в даден пакет се представя в три колони:

колона 1

колона 2

колона 3

флагове за състояние

флагове за тип на файла

път до файла

Възможните стойности на флаговете в първите две колони са както следва:

  • флагове за състояние
  • S - големина на файла
  • M - мод на файла
  • 5 - MD5 сума на файла
  • D - мажорно и минорно число на файла
  • L - символна връзка на файла
  • U - собственик на файла
  • G - група-собственик на файла
  • T - време на последна модификация на файла
  • флагове за тип на файла
  • c - конфигурационен файл
  • d - документация
  • празна колона при бинарните файлове и директории

Ето и примери в команден ред за използването на инструмента rpm за проверка на автентичността и целостта на файловете в рамките на инсталираните пакети в различните нива на подробност:

  • първо ниво на подробност

Първо ниво на подробност може да се реализира чрез подаване на опцията "--verify" на инструмента rpm:

# rpm --verify sendmail

При това ниво на подробност се извеждат единствено резултати, ако има намерени файлове, чиято идентичност не е потвърдена:

S.5....T c /etc/mail/access
S.5....T c /etc/mail/helpfile
S.5....T c /etc/mail/local-host-names
S.5....T c /etc/mail/mailertable
S.5....T c /etc/mail/sendmail.cf
S.5....T c /etc/mail/sendmail.mc
SM5....T c /etc/mail/submit.cf
S.5....T c /etc/mail/submit.mc
S.5....T c /etc/mail/virtusertable

  • второ ниво на подробност

В рамките на второто ниво на подробност освен опцията "--verify", на инструмента rpm се подава и опцията "-v":

# rpm -v --verify sendmail

Във второ ниво на подробност се извеждат всички файлове, налични в пакета, със съответните флагове за състояние и флагове за тип на файла:

........ /etc/mail
........ c /etc/mail/Makefile
S.5....T c /etc/mail/access
........ c /etc/mail/domaintable
S.5....T c /etc/mail/helpfile
S.5....T c /etc/mail/local-host-names
S.5....T c /etc/mail/mailertable
S.5....T c /etc/mail/sendmail.cf
S.5....T c /etc/mail/sendmail.mc
SM5....T c /etc/mail/submit.cf
S.5....T c /etc/mail/submit.mc
........ c /etc/mail/trusted-users
S.5....T c /etc/mail/virtusertable
........ c /etc/pam.d/smtp.sendmail
........ c /etc/rc.d/init.d/sendmail
........ /etc/smrsh
........ c /etc/sysconfig/sendmail
........ /usr/bin/hoststat
........ /usr/bin/mailq.sendmail
........ /usr/bin/makemap
........ /usr/bin/newaliases.sendmail
........ /usr/bin/purgestat
........ /usr/bin/rmail.sendmail
........ c /usr/lib/sasl2/Sendmail.conf
........ /usr/lib/sendmail.sendmail
........ /usr/sbin/mailstats
........ /usr/sbin/makemap
........ /usr/sbin/praliases
........ /usr/sbin/sendmail.sendmail
........ /usr/sbin/smrsh
........ d /usr/share/man/man1/mailq.sendmail.1.gz
........ d /usr/share/man/man1/newaliases.sendmail.1.gz
........ d /usr/share/man/man5/aliases.sendmail.5.gz
........ d /usr/share/man/man8/mailstats.8.gz
........ d /usr/share/man/man8/makemap.8.gz
........ d /usr/share/man/man8/praliases.8.gz
........ d /usr/share/man/man8/rmail.8.gz
........ d /usr/share/man/man8/sendmail.sendmail.8.gz
........ d /usr/share/man/man8/smrsh.8.gz
........ c /var/log/mail/statistics
........ /var/spool/clientmqueue
........ /var/spool/mqueue

  • трето ниво на подробност

В рамките на третото ниво на подробност се използват комбинирано опциите "--verify", и "-vv" на инструмента rpm:

# rpm -vv --verify sendmail

При трето ниво на подробност, в извежданата информация освен пълния списък файлове от пакета и флаговете за състоянието, и флаговете за тип на файла, се получава и списък с криптографските заглавни части (headers) на пакета и зависимостите:

D: opening db environment /var/lib/rpm/Packages joinenv
D: opening db index /var/lib/rpm/Packages rdonly mode=0x0
D: locked db index /var/lib/rpm/Packages
D: opening db index /var/lib/rpm/Name rdonly mode=0x0
D: opening db index /var/lib/rpm/Pubkeys rdonly mode=0x0
D: read h# 290 Header sanity check: OK
D: ========== DSA pubkey id 56d964ae7ad14380
D: read h# 768 Header V3 DSA signature: OK, key ID 7ad14380
D: ========== +++ sendmail-8.13.1-3.RHEL4.3 i386/linux 0x1
D: opening db index /var/lib/rpm/Depends create mode=0x0
D: opening db index /var/lib/rpm/Basenames rdonly mode=0x0
D: read h# 291 Header sanity check: OK
D: ========== DSA pubkey id 219180cddb42a60e
D: read h# 39 Header V3 DSA signature: OK, key ID db42a60e
D: Requires: /bin/bash YES (db files)
D: read h# 38 Header V3 DSA signature: OK, key ID db42a60e
D: Requires: /bin/mktemp YES (db files)
D: Requires: /bin/sh YES (db files)
D: Requires: /bin/sh YES (cached)
D: Requires: /bin/sh YES (cached)
D: Requires: /bin/sh YES (cached)
D: Requires: /bin/sh YES (cached)
D: ========== DSA pubkey id 56d964ae7ad14380
D: read h# 675 Header V3 DSA signature: OK, key ID 7ad14380
D: Requires: /usr/sbin/alternatives YES (db files)
D: read h# 679 Header V3 DSA signature: OK, key ID 7ad14380
D: Requires: /usr/sbin/useradd YES (db files)
D: opening db index /var/lib/rpm/Providename rdonly mode=0x0
D: Requires: bash >= 2.0 YES (db provides)
D: Requires: chkconfig >= 1.3 YES (db provides)
D: Requires: config(sendmail) = 8.13.1-3.RHEL4.3 YES (added provide)
D: Requires: config(sendmail) = 8.13.1-3.RHEL4.3 YES (db provides)
D: ========== DSA pubkey id 219180cddb42a60e
D: read h# 99 Header V3 DSA signature: OK, key ID db42a60e
D: Requires: cyrus-sasl YES (db provides)
D: ========== DSA pubkey id 56d964ae7ad14380
D: read h# 346 Header V3 DSA signature: OK, key ID 7ad14380
D: Requires: fileutils YES (db provides)
D: ========== DSA pubkey id 219180cddb42a60e
D: read h# 63 Header V3 DSA signature: OK, key ID db42a60e
D: Requires: gawk YES (db provides)
D: ========== DSA pubkey id 56d964ae7ad14380
D: read h# 763 Header V3 DSA signature: OK, key ID 7ad14380
D: Requires: libc.so.6 YES (db provides)
D: Requires: libc.so.6(GLIBC_2.0) YES (db provides)
D: Requires: libc.so.6(GLIBC_2.1) YES (db provides)
D: Requires: libc.so.6(GLIBC_2.1.3) YES (db provides)
D: Requires: libc.so.6(GLIBC_2.2) YES (db provides)
D: Requires: libc.so.6(GLIBC_2.3) YES (db provides)
D: Requires: libc.so.6(GLIBC_2.3.4) YES (db provides)
D: Requires: libcrypt.so.1 YES (db provides)
D: read h# 678 Header V3 DSA signature: OK, key ID 7ad14380
D: Requires: libcrypto.so.4 YES (db provides)
D: ========== DSA pubkey id 219180cddb42a60e
D: read h# 34 Header V3 DSA signature: OK, key ID db42a60e
D: Requires: libdb-4.2.so YES (db provides)
D: read h# 125 Header V3 DSA signature: OK, key ID db42a60e
D: Requires: libhesiod.so.0 YES (db provides)
D: ========== DSA pubkey id 56d964ae7ad14380
D: read h# 353 Header V3 DSA signature: OK, key ID 7ad14380
D: Requires: liblber-2.2.so.7 YES (db provides)
D: Requires: libldap-2.2.so.7 YES (db provides)
D: Requires: libnsl.so.1 YES (db provides)
D: Requires: libnsl.so.1(GLIBC_2.0) YES (db provides)
D: Requires: libresolv.so.2 YES (db provides)
D: Requires: libresolv.so.2(GLIBC_2.0) YES (db provides)
D: Requires: libresolv.so.2(GLIBC_2.2) YES (db provides)
D: Requires: libsasl2.so.2 YES (db provides)
D: Requires: libssl.so.4 YES (db provides)
D: ========== DSA pubkey id 219180cddb42a60e
D: read h# 169 Header V3 DSA signature: OK, key ID db42a60e
D: Requires: libwrap.so.0 YES (db provides)
D: Requires: openldap YES (db provides)
D: Requires: openssl YES (db provides)
D: read h# 154 Header V3 DSA signature: OK, key ID db42a60e
D: Requires: procmail YES (db provides)
D: Requires: rpmlib(CompressedFileNames) <= 3.0.4-1 YES (rpmlib provides)
D: Requires: rpmlib(PayloadFilesHavePrefix) <= 4.0-1 YES (rpmlib provides)
D: Requires: rpmlib(VersionedDependencies) <= 3.0.3-1 YES (rpmlib provides)
D: read h# 78 Header V3 DSA signature: OK, key ID db42a60e
D: Requires: sed YES (db provides)
D: ========== DSA pubkey id 56d964ae7ad14380
D: read h# 296 Header V3 DSA signature: OK, key ID 7ad14380
D: Requires: setup >= 2.5.31-1 YES (db provides)
D: Requires: sh-utils YES (db provides)
D: opening db index /var/lib/rpm/Conflictname rdonly mode=0x0
D: closed db index /var/lib/rpm/Depends
........ /etc/mail
........ c /etc/mail/Makefile
S.5....T c /etc/mail/access
........ c /etc/mail/domaintable
S.5....T c /etc/mail/helpfile
S.5....T c /etc/mail/local-host-names
S.5....T c /etc/mail/mailertable
S.5....T c /etc/mail/sendmail.cf
S.5....T c /etc/mail/sendmail.mc
SM5....T c /etc/mail/submit.cf
S.5....T c /etc/mail/submit.mc
........ c /etc/mail/trusted-users
S.5....T c /etc/mail/virtusertable
........ c /etc/pam.d/smtp.sendmail
........ c /etc/rc.d/init.d/sendmail
........ /etc/smrsh
........ c /etc/sysconfig/sendmail
........ /usr/bin/hoststat
........ /usr/bin/mailq.sendmail
........ /usr/bin/makemap
........ /usr/bin/newaliases.sendmail
........ /usr/bin/purgestat
........ /usr/bin/rmail.sendmail
........ c /usr/lib/sasl2/Sendmail.conf
........ /usr/lib/sendmail.sendmail
........ /usr/sbin/mailstats
........ /usr/sbin/makemap
........ /usr/sbin/praliases
........ /usr/sbin/sendmail.sendmail
........ /usr/sbin/smrsh
........ d /usr/share/man/man1/mailq.sendmail.1.gz
........ d /usr/share/man/man1/newaliases.sendmail.1.gz
........ d /usr/share/man/man5/aliases.sendmail.5.gz
........ d /usr/share/man/man8/mailstats.8.gz
........ d /usr/share/man/man8/makemap.8.gz
........ d /usr/share/man/man8/praliases.8.gz
........ d /usr/share/man/man8/rmail.8.gz
........ d /usr/share/man/man8/sendmail.sendmail.8.gz
........ d /usr/share/man/man8/smrsh.8.gz
........ c /var/log/mail/statistics
........ /var/spool/clientmqueue
........ /var/spool/mqueue
D: closed db index /var/lib/rpm/Pubkeys
D: closed db index /var/lib/rpm/Conflictname
D: closed db index /var/lib/rpm/Providename
D: closed db index /var/lib/rpm/Basenames
D: closed db index /var/lib/rpm/Name
D: closed db index /var/lib/rpm/Packages
D: closed db environment /var/lib/rpm/Packages



<< Модулна поддръжка на XFS за RHEL и дериватите му | Управление на зони в динамичен режим чрез nsupdate >>