Предыдущую часть обсуждения мы завершили на такой вот оптимистической ноте: «Подобным образом мы можем изменить поведение любого системного вызова Linux». И тут я слукавил — любого… да не любого. Исключение составляют (могут составлять) группа сетевых системных вызовов, работающих с BSD сокетами. Когда сталкиваешься с этим артефактом в первый раз — это изрядно озадачивает.

Как происходит сокетный вызов

Для прояснения картины воспользуемся заметками одного из непосредственных разработчиков сетевой подсистемы Linux:
Network systems calls on Linux (2008 год). Я коротко перескажу её основное содержание (в интересующей нас части), кому это не интересно может воспользоваться оригиналом.

Когда поддержка BSD сокетов были добавлена в ядро Linux, разработчики решили добавить их единовременно все 17 (на сегодня 20) сокетных вызовов, и добавили для этих вызовов один дополнительный уровень косвенности. Для всей группы этих вызовов введен один новый, редко упоминаемый, системный вызов (см. man socketcall(2)):

int socketcall( int call, unsigned long *args ); 

где:
— call — численный номер сетевого вызова (SYS_CONNECT, SYS_ACCEPT… мы их увидим вскоре);
— args — указатель 6-ти элементного массива (блок параметров), в который последовательно упакованы все параметры любого из системных вызовов этой группы (сетевой), без различения их типа (приведенные к unsigned long);

А вот такой макрос в ядре (<net/socket.c>), в котором «зашито» сколько фактически параметров должен использовать каждый из сокетных вызовов в зависимости от его номера (в диапазоне от 1 до 20):

/* Argument list sizes for sys_socketcall */ 
#define AL(x) ((x) * sizeof(unsigned long)) 
static const unsigned char nargs[ 21 ] = { 
       AL(0),AL(3),AL(3),AL(3),AL(2),AL(3), 
       AL(3),AL(3),AL(4),AL(4),AL(4),AL(6), 
       AL(6),AL(2),AL(5),AL(5),AL(3),AL(3),
       AL(4),AL(5),AL(4)
}; 
#undef AL

(Причём, narg[ 0 ] вообще не используется, потому размерность его и 21.)

Номер сокетного вызова в пространство ядра (int 0x80 или sysenter) передаётся в регистре eax. Значения самих этих констант мы можем подсмотреть в заголовках пространства пользователя (<linux/net.h>):

#define SYS_SOCKET      1               /* sys_socket(2)                */ 
#define SYS_BIND        2               /* sys_bind(2)                  */ 
#define SYS_CONNECT     3               /* sys_connect(2)               */ 
#define SYS_LISTEN      4               /* sys_listen(2)                */ 
#define SYS_ACCEPT      5               /* sys_accept(2)                */ 
...
#define SYS_SENDMSG     16              /* sys_sendmsg(2)               */ 
#define SYS_RECVMSG     17              /* sys_recvmsg(2)               */ 
#define SYS_ACCEPT4     18              /* sys_accept4(2)               */ 
#define SYS_RECVMMSG    19              /* sys_recvmmsg(2)              */ 
#define SYS_SENDMMSG    20              /* sys_sendmmsg(2)              */ 

Собственно, схема обработки к этому моменту уже должна быть понятна:
— необходимое число параметров системного вызова пакуется в массив unsigned long, наибольшее число параметров (6) для SYS_SENDTO=11 (nargs[ 11 ]):

ssize_t sendto( int sockfd, const void *buf, size_t len, int flags, 
                const struct sockaddr *dest_addr, socklen_t addrlen ); 

— адрес сформированного массива передаётся 2-м параметром системного вызова, первым параметром передаётся номер сокетного вызова (например SYS_SENDTO);
— все сокетные вызовы обрабатываются единственным обработчиком ядра sys_socketcall() (__NR_socketcall = 102);
— обработчик сначала копирует из пространства пользователя массив значений-параметров, а далее, в зависимости от eax, копирует из пространства пользователя вослед и области данных, указываемые (возможно) значениями указателей из этого массива параметров.

Некоторые новые архитектуры (так в оригинале) не используют такой непрямой способ вызова, а используют для этих вызовов такую же реализацию, как и для всех остальных системных вызовов. Так это реализовано, в частности, для X86_64 и ARM. Таким образом, даже 64-битовые и 32-битовые (эмулируемые в системе X86_64) приложения будут выполняться по разной схеме. Но не станем на это пока отвлекаться…

Удостовериться в том, что обслуживание сокетных вызовов в 32 и 64 битовых системах осуществляется принципиально по-разному, можно если в каталоге приложений пространства пользователя (заголовочные файлы библиотек языка C, <i386-linux-gnu/asm>) рассмотреть, для сравнения, определения набора системных вызовов для 32 и 64 битовых режимов:

$ cat unistd_32.h | grep socketcall 
#define __NR_socketcall 102 
$ cat unistd_32.h | grep connect 

$ cat unistd_64.h | grep socketcall 
$ cat unistd_64.h | grep connect 
#define __NR_connect 42        

В 32-бит системе присутствует вызов sys_socketcall(), но отсутствуют вызовы для каждого из 20 сокетых вызовов. И напротив, в 64-бит системе отсутствует такой системный вызов как sys_socketcall(), но присутствует весь полный набор системных вызовов для каждого из 20-ти сокетных вызовов.

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

Реализация

Возможность перехвата сетевых системных вызовов будем иллюстрировать на макете распределённого файервола (максимально его упростив). Одно время с этой идеей очень сильно носились, в качестве реализации файервола для больших и сверхбольших сетей (особенно в окружении Cisco). Существует много публикаций на эту тему, например, две из них, дающие полное представление о том, что понимается как распределённый файервол: Implementing a Distributed Firewall и
Automated Implementation of Stateful Firewalls in Linux.

Предложение состоит в том, чтобы контролировать не весь TCP/IP трафик на уровне IP пакетов, а осуществлять регламент на каждом хосте сверхбольшой сети только для протокола TCP и только в момент установления соединения. Под контроль попадают только 2 системных вызова: accept() и connect(). Более глубокое обсуждение распределённого файервола увело бы нас очень далеко от наших целей … рассмотрим только то как мы могли бы контролировать эти сетевые сетевые вызовы.

В качестве иллюстрации реализации перехвата сокетных вызовов был реализован модуль такого сетевого фильтра я ядре для вызовов accept() и connect(). Сделан этот модуль в максимально упрощенной (усечённой) реализации: в качестве параметров при загрузке модуль получает IP адрес (параметр deny) и TCP порт (параметр port), соединения с которыми должны быть запрещены (и ещё один дополнительный параметр debug — уровень диагностического вывода).

Примечание: В тестируемом варианте запрещённые IP адреса и TCP порты допускались множественными, хранились в циклическом списке типа struct list_head (как это и принято повсеместно в ядре), а помещались (или удалялись) они туда отдельным приложением — демоном политики в пространстве пользователя. Фильтр в ядре и должен функционировать некоторым подобным образом, но это слишком громоздко для статьи, описывающей принцип, тем более, что не принцип файервола, а принцип работы с сетевыми системными вызовами. При всех упрощениях код всё ещё великоват, поэтому я помеаю его под спойлер.


Код максимально упрощён, такие вещи, как макросы диагностики LOG(), ERR() уже показывались, отчасти, в предыдущих частях. Функция find() тоже уже обсуждалась. Для записи в защищённую от записи область таблицы sys_call_table существует, как минимум, 3-4 альтернативных варианта, все они назывались и давались ссылками в обсуждениях предыдущей части. Защита от выгрузки модуля на время обслуживания системных вызовов, путём инкремента счётчика ссылок модуля, тоже не показана (называлось в предыдущей части). Все эти подробности присутствуют в кодах прилагаемого архива. Кроме того, коды в архиве обильно пересыпаны комментариями, содержащими выдержки из исходников ядра, с указанием файлов в дереве кодов ядра — это подсказывает требуемые структуры данных.

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

• взять под контроль (сменить обработчик) системного вызова sys_socketcall();
• если код вызова (1-й параметр sys_socketcall()) равен SYS_ACCEPT или SYS_CONNECT, то скопировать из пространства пользователя 3-х элементный массив параметров unsigned long (в общем случае 6 элементов, для SYS_SENDMSG, например);
• 2-й элемент массива (соответствующий 2-му параметру accept() или connect()), хоть он и выглядит как unsigned long — это указатель на struct sockaddr в адресном пространстве пользователя, вторым шагом доступа к параметрам копируем структуру из адресного пространства пользователя;
• структура содержит параметры IP адрес и TCP порт, если они попадают в перечень запрещённых — возвращаем код ошибки и отменяется операция, если нет — вызываем оригинальный обработчик системного вызова;
• для всех остальных (18-ти, не SYS_ACCEPT и SYS_CONNECT) сокетных вызовов просто осуществляем транзитом вызов оригинального sys_socketcall();
• запросы, не относящиеся к протоколу IPv4 без модификации передаются сетевому стеку;

Некоторую дополнительную сложность создаёт тот факт, что для вызова accept() проверку приходится выполнять дважды:

• номер TCP порта раньше оригинального системного вызова, когда сервер начинает прослушивать не присоединенный сокет;
• IP адрес источника после установления соединения для сокета, после возврата из функции оригинального системного вызова;

Как это выглядит в работе? Как-то так:

$ sudo insmod fwnet.ko deny=192.168.56.101 port=10000 debug=1 
$ lsmod | head -n2 
Module                  Size  Used by 
fwnet                  13116  0 
$ dmesg | tail -n10
[  786.609568] ! denied IP: 192.168.56.101 
[  786.609572] ! denied TCP port: 10000 
[  786.613047] ! sys_call_table address = c15b4000 
[  786.636336] ! symbol sys_accept address = c149a070, not found in sys_call_table 
[  786.656437] ! symbol sys_connect address = c149a0a0, not found in sys_call_table 
[  786.661444] ! symbol sys_socketcall address = c149acd0, position in sys_call_table = 102 
[  786.663994] ! CR0 = 8005003b 
[  786.664090] ! CR0 = 8004003b 
[  786.664096] ! CR0 = 8005003b 
[  786.664100] ! install new sys_socketcall handler: e1ad50d0 

Естественно, для того, чтобы наблюдать работу сетевого фильтра ядра в действии, нам необходимы TCP клиент и сервер (например, ncat). Но для детального тестирования были подготовлены специальные ретранслирующий сервер (tcpserv) и клиент (tcpcli). Не считая некоторых мелочей, заточенных под эту работу, они ничего особенного не представляют и рассматриваться здесь не будут (но они есть в прилагаемом архиве).
Вот как будут выглядеть некоторые из попыток установления запрещённых TCP соединений:

— Запуск сервера, прослушивающего запрещённый порт:

$ ./tcpserv -v -p10000 
listening on the TCP port 10000 
denied TCP port: Input/output error 
$ dmesg | tail -n5 
...
[11213.888556] ! accept before: port = 10000 
[11213.888562] ! accept from denied port 10000 

— Попытка подключения клиента к запрещённому порту:

$ ./tcpcli -v -h 127.0.0.1 -p 10000 
client: can't connect to server: Permission denied 
$ dmesg | tail -n5 
...
[10984.082051] ! connect to 127.0.0.1:10000 
[10984.082060] ! connect to 127.0.0.1:10000 denied 
[11166.236948] ! connect to 127.0.0.1:53 
...

Ну и так далее — задача предоставляет широкое и увлекательное поле для экспериментирования…

(Здесь в протоколе специально сохранено и показано обращение в это же время к DNS по порту 53. Точно также, во время экспериментов с фильтрацией можно наблюдать множество соединений к TCP порту 80 — всё время не нарушая работы идёт HTTP трафик.)

Важно то, что после выгрузки модуля работа системы восстанавливается в исходное состояние:

$ sudo rmmod fwnet
$ dmesg | grep \! | tail -n2
[ 2890.602419] ! sys_socketcall handler before unload: e1ad50d0 
[ 2890.602439] ! restore old sys_socketcall handler: c149acd0 

Обсуждение

Вот так, несколько с выдумкой, осуществляется в Linux обработка сетевых системных вызовов … по крайней мере, в 32 бит реализации. При первом столкновении с этими системными вызовами способ их работы несколько обескураживает.

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

Маленький архив кода (и обширный журнал тестирования) для экспериментов можно взять здесь или здесь.