Подробный гайд по программной блокировке Рутокенов в Linux - Часть 3
10. Важные нюансы этого метода
10.1. Это разрушающе-диагностический метод
В момент проверки устройство кратковременно отключается. Если в это время с токеном работает приложение, оно может получить ошибку.
Поэтому лучше:
- выполнять проверку до входа пользователей;
- выполнять проверку в отдельном системном сервисе;
- не выполнять проверку поверх активных криптографических сеансов.
10.2. Библиотека может не сразу видеть изменения
Некоторые PKCS#11-библиотеки кэшируют список слотов.
Если после authorized=0 список токенов не изменился, попробуйте:
- Подождать 1–3 секунды.
- Выполнить
C_Finalize()и повторныйC_Initialize(). - Если используется
pcscd, убедиться, что он получает события подключения/отключения. - В крайнем случае перезапускать
pcscd, но это уже влияет на все токены.
В коде лучше делать так:
попытка 1:
C_GetSlotList()
если изменений нет:
C_Finalize()
C_Initialize()
C_GetSlotList()
10.3. Может исчезнуть несколько серийных номеров
Обычно одно физическое Рутокен-устройство дает один токен.
Но если исчезло сразу несколько серийных номеров, это может означать:
- устройство является составным;
- используется нестандартная конфигурация;
- вы отключили хаб, а не токен;
- библиотека отображает один физический токен как несколько логических слотов.
В таком случае лучше либо блокировать всё устройство целиком, либо разбирать конкретную конфигурацию.
10.4. Если ни один серийный номер не исчез
Возможные причины:
- вы отключили не то устройство;
- библиотека не обновила состояние;
- токен уже был неактивен;
- устройство не используется как смарт-карта;
- устройство заблокировано ранее;
- токен не поддерживается текущей библиотекой.
Если политика безопасности строгая, можно оставить такое устройство заблокированным. Если политика мягкая — можно вернуть его обратно.
11. Можно ли установить соответствие без временного отключения?
Иногда да, но это зависит от конкретной реализации.
11.1. Проверить slotDescription
Посмотрите максимально подробно, что возвращает библиотека.
Например:
pkcs11-tool --module /usr/lib/librtpkcs11ecp.so --list-slots
или:
p11-kit list-tokens --verbose
Иногда в описании слота или токена может быть что-то полезное:
Slot X
Slot description: ...
Token serial: ...
В идеале там может оказаться что-то вроде:
usb-1-2
1-2
bus 1 device 5
/dev/bus/usb/001/005
Если есть — отлично, можно парсить. Но стандарт это не гарантирует.
11.2. Проверить отладочный вывод
Можно посмотреть, какие файлы открывает библиотека.
Например:
strace -f -e trace=openat -o /tmp/pkcs11.log \
pkcs11-tool --module /usr/lib/librtpkcs11ecp.so --list-slots
Затем:
grep '/dev/bus/usb' /tmp/pkcs11.log
Если библиотека открывает:
/dev/bus/usb/001/005
то это уже подсказка. Но если токенов несколько, библиотека может открыть сразу все устройства, и без дополнительного теста будет непонятно, какое устройство какому слоту соответствует.
11.3. Проверить /proc/<pid>/fd
Можно написать небольшую программу:
- Выполнить
C_Initialize(). - Открыть сессию на нужном слоте.
- Сделать паузу.
4. В другом терминале посмотреть:
ls -l /proc/<pid>/fd
Если в открытых файлах есть /dev/bus/usb/..., можно попытаться сопоставить.
Но это тоже не гарантия:
- библиотека может открыть все устройства сразу;
- библиотека может открыть устройство только на время операции;
- библиотека может работать через
pcscd, а не напрямую с/dev/bus/usb.
11.4. Если используется PC/SC
Если Рутокены работают через PC/SC, можно дополнительно смотреть:
pcsc_scan
или запускать pcscd в отладочном режиме.
Иногда имена ридеров содержат индексы, например:
Aktiv Rutoken ECP 00 00
Aktiv Rutoken ECP 01 00
Но сам по себе индекс ридера не обязан однозначно соответствовать sysfs-пути.
Тем не менее, если вы можете управлять токенами через PC/SC, можно комбинировать:
- PC/SC видит появление/исчезновение ридеров;
- PKCS#11 дает серийный номер токена;
- временное отключение USB-устройства позволяет связать ридер/слот с конкретным
sysfs-путем.
12. Вариант для производственного решения: демон rutoken-guard
Для реальной системы лучше сделать отдельный сервис, который:
- Запускается на раннем этапе загрузки.
- Отслеживает события udev.
3. Хранит таблицу:
token_serial -> usb_syspath
или:
usb_port_path -> allowed_token_serial
4. При появлении Рутокена:
- если устройство уже известно и сопоставлено с разрешенным токеном — разрешить;
- если неизвестно — выполнить процедуру сопоставления;
- если токен запрещен — заблокировать.
5. Пишет журнал в journald или отдельный лог.
Архитектура
Например:
+-------------------+
| udev / systemd |
+---------+---------+
|
v
+-------------------+
| rutoken-guard |
+-------------------+
|
+---> sysfs authorized=0/1
+---> PKCS#11 get serials
+---> policy file /etc/rutoken/allowed_serials
+---> mapping cache /var/lib/rutoken-guard/map
Файл разрешенных серийных номеров
# /etc/rutoken/allowed_serials
1234567890ABCDEF
FEDCBA0987654321
Файл соответствий
Например:
{
"1234567890ABCDEF": "/sys/bus/usb/devices/1-2",
"FEDCBA0987654321": "/sys/bus/usb/devices/1-3"
}
Но важно: путь /sys/bus/usb/devices/1-2 может меняться, если токен воткнули в другой порт.
Более стабильно хранить не просто текущий путь, а структуру:
{
"1234567890ABCDEF": {
"usb_path": "1-2",
"last_seen_bus": "1",
"last_seen_devnum": "5",
"last_seen_sysfs": "/sys/bus/usb/devices/1-2"
}
}
Для идентификации порта лучше использовать KERNEL/DEVPATH без busnum/devnum, потому что devnum может меняться.
Например, порт:
1-2
или:
1-2.3
более стабилен для конкретного физического порта, чем busnum/devnum.
Информация предоставлена в ознакомительных целях. Применение описанных настроек в системах, должно осуществляться только после согласования с ответственными за информационную безопасность и в соответствии с требованиями ФСТЭК, ФСБ и иных уполномоченных органов.