Comments 7
Как модуль себя ведёт в многпоточном окружении?
Я получал красивый шар с волосами при массивом su/sudo запуске в параллель на разных сторонних PAM модулях. Не сталкивались или не тестировали?
Как с перехватом авторизации во втором окне? Например в момент авторизации на экране на фоне вредоносный процесс запустит в сабшелле su — он сможет перехватить авторизацию?
Я получал красивый шар с волосами при массивом su/sudo запуске в параллель на разных сторонних PAM модулях. Не сталкивались или не тестировали?
Как с перехватом авторизации во втором окне? Например в момент авторизации на экране на фоне вредоносный процесс запустит в сабшелле su — он сможет перехватить авторизацию?
Насколько я помню, PAM гарантирует корректную работу нескольких приложений с модулем, если каждое их них использует свой хендл к libpam
В связи с этим мне казалось, модулям не надо думать о многопоточности, PAM сам должен это разруливать. По логике построения модуля конечно есть шанс, что кто-то из компании {модуль, pkcs11-библиотека, OpenSSL, токен} может умереть при множественном вызове. Надо бы это проверить, спасибо за совет.
На счет второго вопроса я не совсем понимаю, как это возможно. Опять же, по логике работы с хендлами, PAM не должен дать доступ другому приложению.
The libpam interfaces are only thread-safe if each thread within the multithreaded application uses its own PAM handle.
В связи с этим мне казалось, модулям не надо думать о многопоточности, PAM сам должен это разруливать. По логике построения модуля конечно есть шанс, что кто-то из компании {модуль, pkcs11-библиотека, OpenSSL, токен} может умереть при множественном вызове. Надо бы это проверить, спасибо за совет.
На счет второго вопроса я не совсем понимаю, как это возможно. Опять же, по логике работы с хендлами, PAM не должен дать доступ другому приложению.
интерфейс, а не сами .so'шки — является ли thread-safe сам код модуля? все ли используемые структуры — только динамические и только на хендл завязанные?
по параллельному запросу — на фоне запустился su и запросил пин. на экране запустился визуальный su и тоже пин запросил. на токен ушло два запроса — 1й и 2й в очереди. есть ли гарантия что они придут именно в том порядке в каком ушли в токен?
каков шанс перехвата протокола работы с токеном — только ли ограничено pcscd?
по параллельному запросу — на фоне запустился su и запросил пин. на экране запустился визуальный su и тоже пин запросил. на токен ушло два запроса — 1й и 2й в очереди. есть ли гарантия что они придут именно в том порядке в каком ушли в токен?
каков шанс перехвата протокола работы с токеном — только ли ограничено pcscd?
Да, код завязан только на хендл. В коде есть отдельный условный блок, который компилируется, если объявлен макрос PAM_STATIC. Как я понимаю, это нужно для статической линковки модуля в libpam. По умолчанию этого, естественно, не происходит.
Полный исходный код модуля можно глянуть здесь: www.opensc-project.org/pam_p11/browser/trunk/src
Там его довольно мало, большая часть отведена функции аутентификации и разобрана в статье.
Также я только что проверил множественные логины — все работает корректно, запросы на токен приходят именно в том порядке, в котором и были посланы.
Запрос к токену идет по следующему пути: модуль -> opensc-pkcs11.so -> pcscd -> токен. Теоретически, можно просмотреть APDU-команды, посылаемые токену со стороны pcscd, откуда получить PIN-код. Данное действие будет аналогично установке в систему любого кейлоггера. Плюс использования токена в том, что во-первых, закрытый ключ неизвлекаем, а, во-вторых, токен можно отключать на время, когда не требуется производить аутентификацию.
Полный исходный код модуля можно глянуть здесь: www.opensc-project.org/pam_p11/browser/trunk/src
Там его довольно мало, большая часть отведена функции аутентификации и разобрана в статье.
Также я только что проверил множественные логины — все работает корректно, запросы на токен приходят именно в том порядке, в котором и были посланы.
Запрос к токену идет по следующему пути: модуль -> opensc-pkcs11.so -> pcscd -> токен. Теоретически, можно просмотреть APDU-команды, посылаемые токену со стороны pcscd, откуда получить PIN-код. Данное действие будет аналогично установке в систему любого кейлоггера. Плюс использования токена в том, что во-первых, закрытый ключ неизвлекаем, а, во-вторых, токен можно отключать на время, когда не требуется производить аутентификацию.
Для работы Рутокен S необходима старая версия OpenSC: 0.11.13, а для работы Рутокен ЭЦП – более новая: 0.12.2
Можно пояснить, почему так?
В старых версиях OpenSC (до 0.12.х) криптоалгоритмы, не поддерживаемые токеном аппаратно, реализованы программно. В новых OpenSС по понятным причинам это убрали.
Рутокен S в данной статье стоит рассматривать только с точки зрения обратной совместимости. Для дистрибутивов Linux мы сейчас предлагаем в основном только Рутокен ЭЦП.
Рутокен S в данной статье стоит рассматривать только с точки зрения обратной совместимости. Для дистрибутивов Linux мы сейчас предлагаем в основном только Рутокен ЭЦП.
если один или несколько модулей стека вернут отрицательный ответ, все
остальные модули будут выполнены, но запрос приложения будет отвергнут.
Может быть, здесь имелось в виду "то" а не "но"?
Непонятное предложение.
Sign up to leave a comment.
Разработка и применение модуля PAM для аутентификации в Astra Linux с использованием Рутокен ЭЦП и Рутокен S