UNIX: разработка сетевых приложений - Уильям Стивенс

Функция sysctl предоставляет общий способ получения и хранения параметров операционной системы. При выполнении функции sysctl нас интересует получение следующей информации:

■ список интерфейсов;

■ таблица маршрутизации;

■ кэш ARP.

Изменения API сокетов, требуемые IPv6, включают четыре функции для сопоставления имен интерфейсов и их индексов. Каждому интерфейсу присваивается уникальный положительный индекс. В Беркли-реализациях с каждым интерфейсом уже связан индекс, поэтому нам несложно реализовать эти функции с помощью функции sysctl.

Упражнения

1. Что, как вы считаете, будет хранить поле sdl_len в структуре адреса сокета канального уровня для устройства с именем eth10, адрес канального уровня которого является 64-разрядным адресом IEEE EUI-64?

2. В листинге 18.3 отключите параметр сокета SO_USELOOPBACK перед вызовом функции write. Что происходит?

Глава 19

Сокеты управления ключами

19.1. Введение

С появлением архитектуры безопасности IP (IPSec, см. RFC 2401 [64]) возникла потребность в стандартном механизме управления индивидуальными ключами шифрования и авторизации. Документ RFC 2367 [73] предлагает универсальный интерфейс управления ключами, который может использоваться с IPSec и иными криптографическими сетевыми службами. Подобно маршрутизирующим сокетам, этот интерфейс принадлежит к отдельному семейству протоколов, которое называется PF_KEY. В этом семействе поддерживаются только символьные сокеты.

ПРИМЕЧАНИЕ

Как отмечалось в разделе 4.2, на большинстве систем константа AF_KEY совпадает с PF_KEY. Однако в RFC 2367 совершенно четко утверждается, что с сокетами управления ключами должна использоваться константа PF_KEY.

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

IPSec предоставляет криптографический сервис на базе соглашений о безопасности (security association, SA). Соглашение о безопасности представляет собой сочетание адресов отправителя и получателя (а при необходимости, транспортного протокола и портов), механизма (например, аутентификации) и ключей. К одному потоку трафика может относиться несколько соглашений (например, соглашения об аутентификации и о шифровании). Набор хранящихся в системе соглашений называется базой данных соглашений о безопасности (security association database, SADB).

База SADB может использоваться не только для работы с IPSec. В ней могут иметься записи для OSPFv2, RIPv2, RSVP и Mobile-IP. По этой причине нельзя считать, что сокеты PF_KEY предназначены только для работы с IPSec.

Для работы IPSec необходима также база политик безопасности (security policy database, SPDB). Политики описывают требования к трафику, например: «трафик между узлами А и В должен аутентифицироваться при помощи заголовков аутентификации IPSec (authentication header, АН); не удовлетворяющий требованию трафик должен сбрасываться». База соглашений описывает порядок выполнения требуемых для обеспечения безопасности действий, например, если трафик между узлами А и В использует заголовки аутентификации, то в SADB содержится соответствующий алгоритм и ключи. К сожалению, стандартного механизма управления SPDB не существует. Сокеты PF_KEY работают только с базой SADB, но не с SPDB. Реализация IPSec группы KAME использует для управления SPDB расширения PF_KEY, однако никаким стандартом эти расширения не описываются.

Сокеты управления ключами поддерживают три типа операций:

1. Процесс может отправить сообщение ядру и всем остальным процессам с открытыми сокетами, записав это сообщение в свой сокет. Таким способом добавляются и удаляются записи в базе соглашений о безопасности. Таким же способом процессы, обеспечивающие собственную безопасность самостоятельно (типа OSPFv2), могут запрашивать ключи у демона-ключника (демона, управляющего ключами).

2. Процесс может считать сообщение от ядра или иного процесса через сокет управления ключами. Это позволяет ядру запросить демона-ключника о добавлении соглашения о безопасности для нового сеанса TCP, который, согласно политике, подлежит определенной защите.

3. Процесс может отправить ядру запрос дампа, и ядро в ответ передаст ему дамп текущей базы SADB. Это отладочная функция, которая может быть доступна не во всех системах.

19.2. Чтение и запись

Все сообщения в сокете управления ключами должны иметь одинаковые заголовки, соответствующие листингу 19.1[1]. Сообщение может сопровождаться различными расширениями в зависимости от наличия дополнительной информации или необходимости ее предоставления. Все нужные структуры определяются в заголовочном файле <net/pfkeyv2.h>. Все сообщения и расширения подвергаются 64-разрядному выравниванию и дополняются до длин, кратных 64 разрядам. Все поля длины оперируют 64-разрядными единицами, то есть значение длины 1 означает реальную длину 8 байт. Расширение, не содержащее достаточного количества данных, дополняется произвольным образом до длины, кратной 64 разрядам.

Значение sadb_msg_type задает одну из десяти команд управления ключами. Типы сообщений перечислены в табл. 19.1. За заголовком sadb_msg может следовать произвольное количество расширений. Большинство сообщений имеют обязательные и необязательные расширения, которые будут описаны в соответствующих разделах. Шестнадцать типов расширений с названиями структур, их определяющих, перечислены в табл. 19.3.

Листинг 19.1. Заголовок сообщения управления ключами

struct sadb_msg {

 u_int8_t  sadb_msg_version;  /* PF_KEY_V2 */

 u_int8_t  sadb_msg_type;     /* см. табл. 19.1 */

 u_int8_t  sadb_msg_errno;    /* код ошибки */

 u_int8_t  sadb_msg_satype;   /* см. табл. 19.2 */

 u_int16_t sadb_msg_len;      /* длина заголовка и расширений / 8 */

 u_int16_t sadb_msg_reserved; /* нуль при передаче, игнорируется

                                 при получении */

 u_int32_t sadb_msg_seq;      /* порядковый номер */

 u_int32_t sadb_msg_pid;      /* идентификатор процесса отправителя

                                 или получателя */

};

Таблица 19.1. Типы сообщений

Тип сообщения К ядру От ядра Описание SADB_ACQUIRE • • Запрос на создание записи в SADB SADB_ADD • • Добавление записи в полную базу безопасности SADB_DELETE • • Удаление записи SADB_DUMP • • Дамп SADB (используется для отладки) SADB_EXPIRE • Уведомление об истечении срока действия записи SADB_FLUSH • • Очистка всей базы безопасности SADB_GET • • Получение записи SADB_GETSPI • • Выделение SPI для создания записи SADB SADB_REGISTER • Регистрация для ответа на SADB_ACQUIRE SADB_UPDATE • • Обновление записи в частичной SADB

Таблица 19.2. Типы соглашений о безопасности

Тип соглашения Описание SADB_SATYPE_AH Аутентифицирующий заголовок IPSec SADB_SATYPE_ESP ESP IPSec SADB_SATYPE_MIP Идентификация мобильных пользователей (Mobile IP) SADB_SATYPE_OSPFV2 Аутентификация OSPFv2 SADB_SATYPE_RIPV2 Аутентификация RIPv2 SADB_SATYPE_RSVP Аутентификация RSVP SADB_SATYPE_UNSPECIFIED He определен

Таблица 19.3. Типы расширений PF_KEY