Уильям Стивенс - 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
