RutokenS+AstraLinuxSE1.6+SecretNet(Studio)

Здравствуйте!
Давно не обращался с вопросами подобного характера (с последней темы прошло, ужас, почти 6 лет: https://forum.rutoken.ru/topic/1947/), но время, видимо, пришло :)
Имеется связка:
- сервер под управлением Windows Server 2008/2012 R2 с поднятой службой терминалов;
- СЗИ НСД для сервера Secret Net 7 / Secret Net Studio 8.4;
- клиентский идентификатор Rutoken S с комплектом драйверов под Win и Lin из соответствующего раздела сайта;
- клиентская машина под управлением Linux Mint 19 x64, ядро 4.15;
- клиентская машина под управлением Astra Linux Special Edition 1.6, ядро 4.15;
- программный пакет freerdp-x11 для создания терминальной сессии.

Пытаюсь реализовать схему проброса аппаратного идентификатора (Rutoken S) в терминальную среду (Windows Server) с клиентской nix-машины (Mint / Astra).
На обеих машинах установлены свежие драйверы ifd-rutokens-1.0.4.deb для x64 архитектуры, а также необходимые зависимости:  libccid, pcscd и libpcsclite1. С той лишь разницей, что под Linux Mint имеется пакет pcsc-tools для проверки работы Rutoken S, а под Astra Linux он отсутствует.
В Astra Linux специально отключена поддержка мандатного контроля целостности (МКЦ) через astra-mic-control disable и пользователю (user) превентивно выставлены права работы исключительно в 0 мандатной сессии.

Проблематика

  • Если не устанавливать Secret Net (Secret Net Studio) в терминальную среду Windows Server, то и под Linux Mint, и под Astra Linux проброс Rutoken S через xfreerdp выполняется корректно. Панель управления Рутокен (Windows) "видит" проброшенный токен, позволяет к нему обратиться, отформатировать и т.д.

  • Если установить Secret Net (Secret Net Studio), то из-под Astra Linux проброс "отваливается": при создании терминальной сессии токен несколько раз мигает, но затем обращение к нему полностью прекращается. В результате, токен не видится ни средствами Secret Net (Secret Net Studio), ни средствами Панели управления (Windows) - выводится работы ошибка службы смарт-карт с предложением посетить страницу настройки Рутокена для RDP-сессии. Демон pcscd в свою очередь периодически уходит в inactive режим - приходится его рестартовать через systemctl.

  • Из-под Linux Mint аналогичная связка полностью отрабатывает: токен "виден" и средствами Панели управления, и средствами Secret Net (Secret Net Studio).

Очевидно, что корень зла в компонентах Astra Linux Special Edition, однако никак не могу сообразить, в каких конкретно. Такое ощущение, что обращение к токену средствами Secret Net (Secret Net Studio) в RDP-сессии приводит к переполнению буфера или иной схожей проблеме демона pcscd или самого драйвера Rutoken S.

Собственно, хотел узнать:
- возможно, существует свежий драйвер, разработанный именно под Astra Linux Special Edition и новее 2014 г.в.?
- возможно, что проблема в демоне pcscd или зависимостях (libccid, libpcsclite1) из комплекта Astra Linux Special Edition?
- возможно, имеется определенная схема специальной настройки Astra Linux Special Edition для полной поддержки Rutoken S?

К сожалению, перейти на Рутокен ЭЦП 2.0 не получается - приходится использовать Rutoken S в связи с его сертификатом под "особые" АС...

Re: RutokenS+AstraLinuxSE1.6+SecretNet(Studio)

UPDATE
Обнаружился любопытный факт утром на трезвую голову: при замене СЗИ НСД на Dallas Lock 8.0-C связка заработала без проблем и из-под Astra Linux Special Edition 1.6.
Вывод: Secret Net 7 и Secret Net Studio 8.4-C имеют одинаковую подсистему поддержки Rutoken S, которая некорректно работает в терминальной сессии в некоторых случаях. Точно не могу определить корни зла, но склоняюсь к мысли, что здесь ошибка таймингов обращения к Rutoken S по схеме "подсистема SN (SNS) -> драйвер Рутокен Windows -> подсистема pcscd в Astra Linux -> драйвер ifd-rutokens в Astra Linux". На каком этапе идет сбой самостоятельно пока выяснить не могу...

Re: RutokenS+AstraLinuxSE1.6+SecretNet(Studio)

Здравствуйте, oko.

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

(2019-07-30 19:47:55 отредактировано Алексей Лазарев)

Re: RutokenS+AstraLinuxSE1.6+SecretNet(Studio)

Здравствуйте, oko.

Скажите пожалуйста, а вы не пробовали провести следующий эксперимент: На терминальном сервере установить комплект драйверов с дистрибутивного диска Secret Net Studio 8.4, после чего проверить будет ли возникать проблема описанная в обращении. Суть проблемы в том, что SNS чувствителен к версии драйвера.

И еще момент, можете уточнить, какие защитные компоненты включены в Astra Linux SE 1.6?

UPD. Имеются ввиду драйверы Рутокен для Windows, которые шли на диске. Там должна быть версия 4.3.0.0

С уважением, Алексей Лазарев, Компания "Актив"

(2019-08-01 01:04:15 отредактировано oko)

Re: RutokenS+AstraLinuxSE1.6+SecretNet(Studio)

to Ксения Шаврова
Благодарю! И сразу извиняюсь - не доглядел, что почтовый адрес в Профиле устарел и доступа к нему уже нет (давненько регистрировался, да). Просьба выслать инструкции повторно - e-mail в Профиле обновил на актуальный.

to Алексей Лазарев
Пробовал разные комбинации: брал драйвер для Win из дистрибутива SNS 8.4 (при использовании с SNS 8.4), из дистрибутива SN7 (при использовании с ним), последнюю версию с оф.сайта; также брал последнюю версию драйвера для Linux с оф.сайта и самую первую версию, которая заработала с Астрой 1.3 при прошлом обращении 6 лет назад (ifd...-1.0.1.deb). Результат всегда один (хотя со старым драйвером для Linux наблюдалось еще и постоянное мигание светодиода Рутокен S, но, думаю, это не критично):

  • при подключении из-под Win 8.1 к Win Server 2008R2/2012R2 или из-под Linux Mint (не принципиально, как мне кажется) к Win Server 2008R2/2012R2 Rutoken S корректно пробрасывается RDP-клиентом, "виден" в Панели управления Рутокеном, а также "виден" всеми механизмами SNS (SN7);

  • при подключении из-под Astra Linux SE 1.6 к Win Server 2008R2/2012R2 Rutoken S пару раз мигает (с последним драйвером для Linux), будто бы идет опрос, но в терминальной сессии ни Панель управления Рутокеном, ни SNS (SN7) его уже "не видят" (Панель выдает стандартную ошибку, будто бы не включена служба поддержки смарт-карт)

Проброс Rutoken S в терминальную среду делаю через:

/usr/bin/xfreerdp /sec:rdp /cert-ignore /smartcard:"0a89:0020" /v:192.168.1.1

Правила udev для Rutoken S:

SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="0a89", ATTRS{idProduct}=="0020", RUN+="/bin/systemctl start rutoken.service"
SUBSYSTEM=="usb", ACTION=="remove", ENV{ID_VENDOR_ID}=="0a89", ENV{ID_MODEL_ID}=="0020", RUN+="/bin/systemctl stop rutoken.service"

Systemd-сервис для Rutoken S:

[Unit]
Description=Rutoken S (un)plug service
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/RutokenS.sh plug
ExecStop=/usr/bin/RutokenS.sh unplug

Впрочем, systemd-сервис и правила udev модифицированы под нужную задачу (скрипт RutokenS.sh выполняет доп.действия при подключении токена, но также выполняет chgrp для /dev/usb..., как и в оригинале после установки драйвера). Если их оставить по умолчанию (после установки драйвера), все равно ничего принципиально не меняется.
В ходе ковыряния проблемы на стенде дошел до того, что отключил почти все защитные механизмы Astra Linux, до которых смог добраться: мандатный контроль целостности, модули Parsec для PAM, киоск, затирание, мандатные метки уровня файловой системы. Но проблема осталась...

К сожалению, в "репозитории" (диск установки) Astra Linux SE 1.6 отсутствует пакет pcsc-tools, поэтому непосредственную отладку через консоль не проводил. Если необходимо, могу встроить аналогичный пакет от Debian 9 и проверить вывод.
Любопытный факт: после пары-тройки подключений к терминальному серверу с подключенным Rutoken S, сервис pcscd переходит в состояние inactive и требует перезапуска. Почему и грешу на переполнение буфера...

ЗЫ Складывается ощущение (особенно после заработавшей связи с Dallas Lock 8.0-C), что SNS (SN7) производит слишком много "лишних" обращений к Rutoken S, в результате чего служба в Astra Linux не выдерживает и "отбивает"...

Re: RutokenS+AstraLinuxSE1.6+SecretNet(Studio)

Добрый день, разработчики SN провели исследование. Вот их вердикт:

«Описанная проблема заключается в используемом терминальном клиенте. В нём не в полной мере реализован стандартный интерфейс WinsCard. В частности, функция ScardLocateCardsByATR().
Можем рекомендовать сменить терминальный клиент или его версию. Мы учтем этот момент а будущих версиях и вероятно поддержим клиентов даже без этой функции. Но это не ошибка нашего продукта. Это недоработка используемого терминального клиента.»

С уважением, Алексей Лазарев

С уважением, Алексей Лазарев, Компания "Актив"

Re: RutokenS+AstraLinuxSE1.6+SecretNet(Studio)

Спасибо!
Значит, придется делать откат до freerdp-x11 версии 1.x, вместо включенной в дистрибутив по умолчанию версии 2.0. С учетом того, что в аналогичной связке, но с Astra Linux Special Edition 1.5 (где как раз freerdp-x11 версии 1.1.0) тоже проверил - результат положительный...
Надо будет еще в багтрек Debian 9 или авторам freerdp-x11 сообщить, чтобы пофиксили проблему в следующих релизах...

Тему можно закрывать. Еще раз спасибо!