Журнал LinuxFormat - перейти на главную

LXF83:Hardcore Linux

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(Укрепляем USB)
м (категория)
 
(не показаны 5 промежуточных версий 2 участников)
Строка 6: Строка 6:
  
 
=== Предостережение ===
 
=== Предостережение ===
Коль скоро вы соблюдаете обычную меру предосторожности, резерви-
+
Коль скоро вы соблюдаете обычную меру предосторожности, резервируя все редактируемые файлы, при испытании этого USB-проекта беспокоиться особо не о чем. Но всё будет немного иначе, если вы планируете использовать USB-аутентификацию в реальном окружении, как первую линию обороны от пользователей, пытающихся обольстить вашу систему с целью получения неавторизованного доступа. В этом случае единственное требование – убедитесь, что PAM настроен как надо. Нужно также ограничить физический доступ к машине и заблокировать все не в меру вольные сервисы, запущенные на вашей системе. Даже когда пользователи аутентифицируются исключительно при помощи USB-брелка, злоумышленник сможет получить административный доступ к вашей системе, просто нажав кнопку «Reset» и перегрузив ваш дистрибутив в безопасный режим (failsafe mode).
руя все редактируемые файлы, при испытании этого USB-проекта беспо-
+
 
коиться особо не о чем. Но всё будет немного иначе, если вы планируете
+
Если вы планируете использовать PAM, чтобы защитить свою систему таким способом, важно также иметь стратегию ограничения физического доступа к вашему компьютеру. Простое решение – запереть компьютер в защищённом помещении и подключить к USB-хабу, запертому в вашем столе. Так могут делать люди, желающие обезопасить свои драгоценные «USB-замки» для программной аутентификации, и вы можете это использовать для PAM-аутентификации. В любом случае, безопасность определяется самым слабым звеном в цепи.
использовать USB-аутентификацию в реальном окружении, как первую
+
 
линию обороны от пользователей, пытающихся обольстить вашу систе-
+
== Шаг 1 – Зачем нужен PAM ==
му с целью получения неавторизованного доступа. В этом случае единс-
+
Прежде чем зарываться в настройку PAM, стоит рассмотреть это приложение как таковое. Программа была разработана в Sun Microsystems в 1996 году, с целью навести порядок в широком спектре механизмов аутентификации, использовавшихся в начале 90-х.
твенное требование – убедитесь, что PAM настроен как надо. Нужно
+
 
также ограничить физический доступ к машине и заблокировать все не
+
Проблема тогда заключалась в том, что не существовало единого унифицированного интерфейса, используемого при аутентификации пользователей. Тем, кто разрабатывал инструменты, требующие входа (login), приходилось вручную связывать свое приложение с необходимым методом (или методами) аутентификации. Хороший пример – Linux-команда login, генерирующая приглашение ввести имя пользователя на виртуальных терминалах. До PAM login нужно было связывать с каждым механизмом аутентификации, угодным автору, а это могли быть столь несходные методы, как шифрованные пароли, биометрия и всевозможные смарт-карты. Разработчикам было нелегко заниматься сопровождением в этой ситуации. Если администратор решал изменить механизм аутентификации, нужно было перенастраивать все приложения, которые его использовали.
в меру вольные сервисы, запущенные на вашей системе. Даже когда
+
 
пользователи аутентифицируются исключительно при помощи USB-
+
Вот почему появился PAM. PAM размещается между тем, что называется сервисами (в основном, login и другие программы «системного входа»), нуждающимися в механизме аутентификации, и самим механизмом. В сервис нужно только встроить поддержку PAM – и употреблять любой метод аутентификации, предусмотренный в PAM. Пока login использует PAM, разработчику больше ни о чем думать не нужно: это забота PAM, и если вам нужно изменить механизм аутентификации для login, ftp или su, PAM – единственное место, где это нужно делать.
брелка, злоумышленник сможет получить административный доступ к
+
вашей системе, просто нажав кнопку «Reset» и перегрузив ваш дистри-
+
бутив в безопасный режим (failsafe mode).
+
Если вы планируете использовать PAM, чтобы защитить свою сис-
+
тему таким способом, важно также иметь стратегию ограничения физи-
+
ческого доступа к вашему компьютеру. Простое решение – запереть ком-
+
пьютер в защищённом помещении и подключить к USB-хабу, запертому
+
в вашем столе. Так могут делать люди, желающие обезопасить свои дра-
+
гоценные «USB-замки» для программной аутентификации, и вы можете
+
это использовать для PAM-аутентификации. В любом случае, безопас-
+
ность определяется самым слабым звеном в цепи.
+
Прежде чем зарываться в настройку PAM, стоит рассмотреть это при-
+
ложение как таковое. Программа была разработана в Sun Microsystems
+
в 1996 году, с целью навести порядок в широком спектре механизмов
+
аутентификации, использовавшихся в начале 90-х.
+
Проблема тогда заключалась в том, что не существовало единого
+
унифицированного интерфейса, используемого при аутентификации
+
пользователей. Тем, кто разрабатывал инструменты, требующие входа
+
(login), приходилось вручную связывать свое приложение с необхо-
+
димым методом (или методами) аутентификации. Хороший пример –
+
Linux-команда login, генерирующая приглашение ввести имя пользова-
+
теля на виртуальных терминалах. До PAM login нужно было связывать
+
с каждым механизмом аутентификации, угодным автору, а это могли
+
быть столь несходные методы, как шифрованные пароли, биометрия и
+
всевозможные смарт-карты. Разработчикам было нелегко заниматься
+
сопровождением в этой ситуации. Если администратор решал изменить
+
механизм аутентификации, нужно было перенастраивать все приложе-
+
ния, которые его использовали.
+
Вот почему появился PAM. PAM размещается между тем, что назы-
+
вается сервисами (в основном, login и другие программы «системного
+
входа»), нуждающимися в механизме аутентификации, и самим меха-
+
низмом. В сервис нужно только встроить поддержку PAM – и употреб-
+
лять любой метод аутентификации, предусмотренный в PAM. Пока login
+
использует PAM, разработчику больше ни о чем думать не нужно: это
+
забота PAM, и если вам нужно изменить механизм аутентификации для
+
login, ftp или su, PAM – единственное место, где это нужно делать.
+
  
 
=== И аутентификация всей страны! ===
 
=== И аутентификация всей страны! ===
Как правило, файлы конфигурации PAM находятся в каталоге
+
Как правило, файлы конфигурации PAM находятся в каталоге '''/etc/pam.d''' вашей файловой системы. Этот каталог содержит файлы конфигурации всех приложений с аутентификацией через PAM, обычно включающие записи для стандартных сервисов, например, gdm, xdm, cups и даже screensaver – почти всех, в которых требуется пароль.
/etc/pam.d вашей файловой системы. Этот каталог содержит файлы
+
 
конфигурации всех приложений с аутентификацией через PAM, обычно
+
Взглянув на любой конфигурационный файл PAM, вы увидите нечто подобное (взято из gdm в SUSE 10.1):
включающие записи для стандартных сервисов, например, gdm, xdm,
+
 
cups и даже screensaver – почти всех, в которых требуется пароль.
+
auth       include   common-auth
Взглянув на любой конфигурационный файл PAM, вы увидите нечто
+
account     include   common-account
подобное (взято из gdm в SUSE 10.1):
+
password   include   common-password
auth include common-auth
+
session     include   common-session
account include common-account
+
 
password include common-password
+
<!--
session include common-session
+
{|style="background-color:#c0c0ff;" cellpadding="3"
Каждый столбец этого конфигурационного файла представляет
+
|auth
одну из четырёх директив. Это тип интерфейса модуля (первый стол-
+
|include
бец), флаг управления (второй столбец), путь к модулю (третий столбец)
+
|common-auth
и любые аргументы модуля (в примере gdm их нет, поэтому столбец
+
|-
пустой). Интерфейс модуля и сам имеет четыре варианта, каждый
+
|account
из которых показан в нашем примере – auth, account, password и
+
|include   
session. Модули auth будут аутентифицировать пользователей, что
+
|common-account
обычно означает проверку соответствия имени пользователя и пароля.
+
|-
Затем идут модули account, проверяющие правильность учётной запи-
+
|password   
си. Password, естественно, проверяет пароль, а session обеспечива-
+
|include
ет выполнение всего, что полагается сделать перед предоставлением
+
|common-password
сервиса пользователю, например, монтирование пользовательского
+
|-
домашнего или почтового каталога.
+
|session
Наиболее важный столбец – второй, флаг управления; его-то мы
+
|include
и будем менять в нашем новом модуле, чтобы изменить требования
+
|common-session
аутентификации, когда вставлен USB-брелок. В нашем куске кода из
+
|}
конфигурационного файла gdm все четыре поля установлены в include.
+
!-->
Это особый случай, поскольку ключевое слово include на самом деле
+
 
указывает PAM направление к другому конфигурационному файлу в
+
Каждый столбец этого конфигурационного файла представляет одну из четырёх директив. Это тип интерфейса модуля (первый столбец), флаг управления (второй столбец), путь к модулю (третий столбец) и любые аргументы модуля (в примере gdm их нет, поэтому столбец пустой). Интерфейс модуля и сам имеет четыре варианта, каждый из которых показан в нашем примере – auth, account, password и session. Модули auth будут аутентифицировать пользователей, что обычно означает проверку соответствия имени пользователя и пароля. Затем идут модули account, проверяющие правильность учётной записи. Password, естественно, проверяет пароль, а session обеспечивает выполнение всего, что полагается сделать перед предоставлением сервиса пользователю, например, монтирование пользовательского домашнего или почтового каталога.
третьем поле (common-auth). Этот файл содержит общие правила,
+
 
пригодные для различных сервисов. Содержимое файла login указы-
+
Наиболее важный столбец – второй, флаг управления; его-то мы и будем менять в нашем новом модуле, чтобы изменить требования аутентификации, когда вставлен USB-брелок. В нашем куске кода из конфигурационного файла gdm все четыре поля установлены в include. Это особый случай, поскольку ключевое слово include на самом деле указывает PAM направление к другому конфигурационному файлу в третьем поле (common-auth). Этот файл содержит общие правила, пригодные для различных сервисов. Содержимое файла login указывает туда же.
вает туда же.
+
 
Открыв файл /etc/pam.d/common-auth, вы увидите нечто вроде
+
Открыв файл '''/etc/pam.d/common-auth''', вы увидите нечто вроде следующего (если вы используете старую версию PAM, эта информация будет в файле gdm):
следующего (если вы используете старую версию PAM, эта информация
+
 
будет в файле gdm):
+
auth   required   pam_env.so
auth required pam_env.so
+
auth   required   pam_unix2.so
auth required pam_unix2.so
+
 
Когда пользователь входит в систему, модуль аутентификации
+
Когда пользователь входит в систему, модуль аутентификации передаёт сигнал к флагу управления практически тем же способом, как возвращают сигналы процессы и функции. Этот сигнал сообщает о том, что происходило, пока процес или функция исполнялась. Есть сигналы для «успеха» и «неудачи», а есть и сигналы для ошибок сервиса или оповещения, что учётная запись устарела. С новыми версиями PAM вы можете создавать собственные правила для любого из этих условий, это облегчает обработку исключений.
передаёт сигнал к флагу управления практически тем же способом, как
+
 
возвращают сигналы процессы и функции. Этот сигнал сообщает о том,
+
Приведённый выше фрагмент включает более типичный флаг управления – required. Он говорит PAM, что модуль auth обязан завершиться успешно. Менее строгий флаг управления – sufficient, означающий, что если аутентификация для этого модуля успешна, системе PAM не нужно продолжать аутентификацию какими-нибудь другими модулями, чтобы предоставить доступ. Другой общий флаг управления – optional, который, как подсказывает название, не критичен для предоставления доступа. Причина, почему существуют меняющиеся степени «успешности», заключается в том, что вы можете объединить модули вместе и проектировать аутентификацию на основе «успешности» отдельного модуля или стека из нескольких – именно то, как мы будем настраивать нашу аутентификацию по USB.
что происходило, пока процес или функция исполнялась. Есть сигналы
+
 
для «успеха» и «неудачи», а есть и сигналы для ошибок сервиса или
+
== Шаг 2 - Установка модуля USB ==
оповещения, что учётная запись устарела. С новыми версиями PAM вы
+
 
можете создавать собственные правила для любого из этих условий, это
+
{{Врезка
облегчает обработку исключений.
+
|Заголовок=Обзор модуля
Приведённый выше фрагмент включает более типичный флаг управ-
+
|Содержание=Каждый конфигурационный файл PAM использует одну строку из четырех столбцов:
ления – required. Он говорит PAM, что модуль auth обязан завершиться
+
Интерфейс модуля    Флаг управления    Путь к модулю    Опции
успешно. Менее строгий флаг управления – sufficient, означающий,
+
auth                include            common-auth      null
что если аутентификация для этого модуля успешна, системе PAM не
+
|Ширина=450px
нужно продолжать аутентификацию какими-нибудь другими модулями,
+
}}
чтобы предоставить доступ. Другой общий флаг управления – optional,
+
 
который, как подсказывает название, не критичен для предоставления
+
Модуль USB, который нам понадобится, разрабатывается отдельно от основного приложения PAM, и пока считается не завершенным, хотя на самом деле полностью функционален. Называется он Pam_usb, и его можно найти на нашем диске или на [http://www.pamusb.org www.pamusb.org]. Последняя версия выпущена в октябре 2005 года, но она работает с ядрами 2.6 и современными дистрибутивами.
доступа. Причина, почему существуют меняющиеся степени «успеш-
+
 
ности», заключается в том, что вы можете объединить модули вместе
+
Первый шаг – скачать исходный код с сайта Pam_usb. Сборка и инсталляция модуля очень просты: наберите '''make''', затем – '''make install''' с правами root , а конфигурационного скрипта здесь нет. Будет установлена пара скриптов hotplug и создан каталог '''/etc/pam_usb'''. Кроме того, в '''/usr/bin''' будет установлен инструмент администрирования usbadm. Скрипт hotplug разработан для блокировки сеанса, когда извлекается USB-устройство, используемое для аутентификации.
и проектировать аутентификацию на основе «успешности» отдельного
+
модуля или стека из нескольких – именно то, как мы будем настраивать
+
нашу аутентификацию по USB.
+
Модуль USB, который нам понадобится, разрабатывается отдельно от
+
основного приложения PAM, и пока считается не завершенным, хотя
+
на самом деле полностью функционален. Называется он Pam_usb, и
+
его можно найти на нашем диске или на www.pamusb.org. Последняя
+
версия выпущена в октябре 2005 года, но она работает с ядрами 2.6 и
+
современными дистрибутивами.
+
Первый шаг – скачать исходный код с сайта Pam_usb. Сборка и инс-
+
талляция модуля очень просты: наберите make, затем – make install
+
с правами root , а конфигурационного скрипта здесь нет. Будет установ-
+
лена пара скриптов hotplug и создан каталог /etc/pam_usb. Кроме того,
+
в /usr/bin будет установлен инструмент администрирования usbadm.
+
Скрипт hotplug разработан для блокировки сеанса, когда извлекается
+
USB-устройство, используемое для аутентификации.
+
  
 
=== Сидеть! Место! ===
 
=== Сидеть! Место! ===
Очень важно, чтобы ваше устройство USB всегда обнаруживалось в
+
Очень важно, чтобы ваше устройство USB всегда обнаруживалось в одном и том же месте. Горячее подключение USB-устройств печально известно в Linux как ненадёжное, но многие из последних дистрибутивов, похоже, наконец-то заставят его работать. Сложность заключается в том, что модулю Pam_usb необходимо находить устройство USB в одной и той же точке монтирования, когда бы вы ни подключили его к машине.
одном и том же месте. Горячее подключение USB-устройств печально
+
 
известно в Linux как ненадёжное, но многие из последних дистрибути-
+
К тому же, настоятельно рекомендуется, чтобы устройства монтировали себя сами (используя hotplug); в противном случае вы завязнете, если не сможете войти на машину и разобраться с хулиганящим USB-оборудованием. Я обнаружил, что и SUSE 10.1, и Ubuntu 6.06 работают без каких-либо дополнительных ухищрений. Современные дистрибутивы монтируют эти устройства согласно их идентификаторам, назначенным изготовителем и определяемым скриптом hotplug при опросе USB (вы можете сделать это сами, набрав '''lsusb'''). Когда вы сможете достоверно находить ваше устройство USB в файловой системе, вам потребуется передать эту информацию в usbadm; она автоматически создаст ключи, необходимые для шифрования, чтобы защитить вашу информацию, и скопирует все файлы конфигурации на их законные места в файловой системе и на USB-брелок.
вов, похоже, наконец-то заставят его работать. Сложность заключается
+
 
в том, что модулю Pam_usb необходимо находить устройство USB в
+
[[Изображение:Img_83_76_1.png|thumb|Создание ключа шифрования DSA с помощью usbadm очень похоже на генерацию ключа с помощью GnuPG – и не удивительно, поскольку оба используют один и тот же вид шифрования.]]
одной и той же точке монтирования, когда бы вы ни подключили его
+
 
к машине.
+
Отданная вами команда должна выглядеть следующим образом – только измените имя пользователя и размещение вашего USB-устройства:
К тому же, настоятельно рекомендуется, чтобы устройства монтиро-
+
 
вали себя сами (используя hotplug); в противном случае вы завязнете,
+
usbadm keygen /media/KINGSTON graham 1024
если не сможете войти на машину и разобраться с хулиганящим USB-
+
 
оборудованием. Я обнаружил, что и SUSE 10.1, и Ubuntu 6.06 работают
+
В этом примере /media/KINGSTON – точка монтирования USB-брелка, graham – имя пользователя, а 1024 – размер DSA-ключа шифрования, который должен сгенерироваться. Фактически эта команда размещает открытый ключ в '''.auth''' в пользовательском каталоге, а закрытый ключ в '''.auth''' на USB-устройстве. Тем, кто знаком с шифрованием парным ключом, известно, что неважно, кому доступен публичный ключ – но каждый владелец копии закрытого ключа сможет пройти аутентификацию и войти на вашу машину. Другими словами, любая личность, присвоившая ваше USB-устройство...
без каких-либо дополнительных ухищрений. Современные дистрибу-
+
тивы монтируют эти устройства согласно их идентификаторам, назна-
+
ченным изготовителем и определяемым скриптом hotplug при опросе
+
USB (вы можете сделать это сами, набрав lsusb). Когда вы сможете
+
достоверно находить ваше устройство USB в файловой системе, вам
+
потребуется передать эту информацию в usbadm; она автоматически
+
создаст ключи, необходимые для шифрования, чтобы защитить вашу
+
информацию, и скопирует все файлы конфигурации на их законные
+
места в файловой системе и на USB-брелок.
+
Отданная вами команда должна выглядеть следующим обра-
+
зом – только измените имя пользователя и размещение вашего
+
USB-устройства:
+
usbadm keygen /media/KINGSTON graham 1024
+
В этом примере /media/KINGSTON – точка монтирования USB-
+
брелка, graham – имя пользователя, а 1024 – размер DSA-ключа
+
шифрования, который должен сгенерироваться. Фактически эта коман-
+
да размещает открытый ключ в .auth в пользовательском каталоге, а
+
закрытый ключ в .auth на USB-устройстве. Тем, кто знаком с шифро-
+
ванием парным ключом, известно, что неважно, кому доступен публич-
+
ный ключ – но каждый владелец копии закрытого ключа сможет пройти
+
аутентификацию и войти на вашу машину. Другими словами, любая
+
личность, присвоившая ваше USB-устройство...
+
  
 
=== Укрепляем USB ===
 
=== Укрепляем USB ===
Строка 166: Строка 92:
 
Есть два решения этой проблемы. Первая – держать ваш закрытый ключ на USB-устройстве с определенным серийным номером. Модуль Pam_usb может затем проверять этот серийный номер и убеждаться, что приватный ключ не был скопирован.
 
Есть два решения этой проблемы. Первая – держать ваш закрытый ключ на USB-устройстве с определенным серийным номером. Модуль Pam_usb может затем проверять этот серийный номер и убеждаться, что приватный ключ не был скопирован.
  
Если ваше USB-устройство снабжено встроенным серийным номером, вы можете запросить его и добавить его к модулю, набрав usbadm addserial, или добавить его вручную, введя usbadm addserial 12345. Серийный номер добавляется к /etc/pam_usb/serials.conf. Использовать серийные номера таким способом не совсем безопасно – отчасти потому, что программисту относительно легко раскрыть серийный номер, хранящийся в вашем устройстве, а отчасти потому, что так мало USB-брелков действительно снабжены серийный номер. Итак, подумаем над альтернативным решением.
+
Если ваше USB-устройство снабжено встроенным серийным номером, вы можете запросить его и добавить его к модулю, набрав '''usbadm addserial''', или добавить его вручную, введя '''usbadm addserial 12345'''. Серийный номер добавляется к '''/etc/pam_usb/serials.conf'''. Использовать серийные номера таким способом не совсем безопасно – отчасти потому, что программисту относительно легко раскрыть серийный номер, хранящийся в вашем устройстве, а отчасти потому, что так мало USB-брелков действительно снабжены серийный номер. Итак, подумаем над альтернативным решением.
  
 
=== Двойная защита ===
 
=== Двойная защита ===
Строка 173: Строка 99:
 
Решение, оно же моя альтернатива использованию серийного номера – двухкаскадная аутентификация, задействующая два различных метода одновременно. Здесь безопасность USB-брелка должна играть важную роль. Комбинация приватного ключа, размещённого на USB-брелке, и обычной аутентификации по паролю предоставляет сильный уровень системной безопасности и защищает от наиболее общей атаки на безопасность: подбора пароля. При использовании двух методов аутентификации, даже если пароль будет угадан, потенциальному злоумышленнику всё-таки не обойтись без закрытого ключа с вашего USB-брелка. В PAM это означает стековую аутентификацию, и на следующей странице я покажу вам, как её настроить.
 
Решение, оно же моя альтернатива использованию серийного номера – двухкаскадная аутентификация, задействующая два различных метода одновременно. Здесь безопасность USB-брелка должна играть важную роль. Комбинация приватного ключа, размещённого на USB-брелке, и обычной аутентификации по паролю предоставляет сильный уровень системной безопасности и защищает от наиболее общей атаки на безопасность: подбора пароля. При использовании двух методов аутентификации, даже если пароль будет угадан, потенциальному злоумышленнику всё-таки не обойтись без закрытого ключа с вашего USB-брелка. В PAM это означает стековую аутентификацию, и на следующей странице я покажу вам, как её настроить.
  
Теперь вникнем в детали добавления нового метода PAM-аутентификации. Для начала, нам нужно выбрать сервис, который мы хотим запереть с помощью нашего USB-ключа. Вышеупомянутый login – хорошая стартовая точка, отчасти потому, что его легко использовать, а отчасти – потому что не будет большой беды, если вы что-то заблокируете (если, конечно, это не удалённая система, и login – не единственный способ подключиться к ней). Скрипт конфигурации PAM для login можно найти в /etc/pam.d/login; откройте его в своём любимом редакторе (или в нелюбимом, если вам нужно встряхнуться).
+
== Шаг 3 - Ваша конфигурация PAM ==
  
Нам нужно проверить, что Pam_usb работает, и простейший способ проверки – убедиться, что это единственный метод, требуемый для входа в систему, для чего мы закомментируем строку, включающую auth required pam_unix2.so. Если такой строки нет, вероятно, найдётся строка с директивой include, указывающей на файл с именем common-auth. Просмотрите содержимое этого файла, и найдете auth required pam_unix2.so – но здесь это закомментировать было бы глупо, потому что тогда любой другой сервис, включающий common-auth, не сможет выполнить аутентификацию и блокирует вашу систему.
+
{{Врезка
 +
|Заголовок=PAM ограничивает учётные записи пользователей
 +
|Содержание=PAM также можно использовать для ограничения прав пользователя в вашей системе. Это может быть ограничение на дисковое пространство или даже на допустимый расход ресурсов процессора. Чтобы установить всё это, потребуется отредактировать файл /etc/security/limits.conf. Простые правила могут выглядеть следующим образом:
  
Вместо этого скопируйте содержимое из common-auth в login, и закомментируйте обе строки – include, указывающую на этот файл, и строку, заканчивающуюся на pam_unix2.so. Затем добавьте auth require pam_usb.so; получится нечто вроде
+
*            hard      core        0
 +
*            hard      rss        20000
 +
@users      hard      nproc      100
 +
@lusers      hard      cpu        10
 +
@users      hard      fsize      100000
 +
 
 +
Первый столбец определяет круг пользователей, на которых распространяется данное правило. Вы можете использовать символ подстановки *, чтобы указать всех пользователей, или определить идентификатор группы после символа @. В следующемстолбце указывается, жёсткое это ограничение (hard) или мягкое (soft). (Мягкие ограничения пользователь может менять, а жёсткие – нет). Третий столбец – суть ограничения. Первое ограничение, core, не даст пользователю создать никаких core-файлов, потому что параметр установлен в 0. Второй, rss, – это объём резидентной памяти, предоставляемой пользователю
 +
для его приложений, тогда как nproc – число процессов, которые ему позволено запустить. Четвёртая категория, cpu, ограничивает процент тактов процессора, которые пользователь может использовать, а fsize – размер любого файла, создаваемого пользователем.
 +
 
 +
Вам также нужно будет убедиться, что в конфигурационный файл login, тот самый, который мы редактировали в основном тексте, добавлена следующая строка:
 +
 
 +
session    required      /lib/security/pam_limits.so
 +
 
 +
|Ширина=450px
 +
}}
 +
 
 +
Теперь вникнем в детали добавления нового метода PAM-аутентификации. Для начала, нам нужно выбрать сервис, который мы хотим запереть с помощью нашего USB-ключа. Вышеупомянутый login – хорошая стартовая точка, отчасти потому, что его легко использовать, а отчасти – потому что не будет большой беды, если вы что-то заблокируете (если, конечно, это не удалённая система, и login – не единственный способ подключиться к ней). Скрипт конфигурации PAM для login можно найти в '''/etc/pam.d/login'''; откройте его в своём любимом редакторе (или в нелюбимом, если вам нужно встряхнуться).
 +
 
 +
[[Изображение:Img_83_77_1.png|thumb|Это – рабочий файл конфигурации PAM из SUSE 10.1, модифицированный добавкой модуля Pam_usb.]]
 +
 
 +
Нам нужно проверить, что Pam_usb работает, и простейший способ проверки – убедиться, что это единственный метод, требуемый для входа в систему, для чего мы закомментируем строку, включающую auth required pam_unix2.so. Если такой строки нет, вероятно, найдётся строка с директивой include, указывающей на файл с именем '''common-auth'''. Просмотрите содержимое этого файла, и найдете auth required pam_unix2.so – но здесь это закомментировать было бы глупо, потому что тогда любой другой сервис, включающий common-auth, не сможет выполнить аутентификацию и блокирует вашу систему.
 +
 
 +
Вместо этого скопируйте содержимое из '''common-auth''' в login, и закомментируйте обе строки – include, указывающую на этот файл, и строку, заканчивающуюся на pam_unix2.so. Затем добавьте auth require pam_usb.so; получится нечто вроде
 +
 
 +
auth    required    pam_usb.so
 +
auth    required    pam_env.so
 +
#auth    required    pam_unix2.so
 +
#auth    include    common-auth
 +
 
 +
<!--
 
{|style="background-color:#c0c0ff;" cellpadding="3"
 
{|style="background-color:#c0c0ff;" cellpadding="3"
 
|auth
 
|auth
Строка 195: Строка 152:
 
|common-auth
 
|common-auth
 
|}
 
|}
 +
!-->
  
 
Переключитесь в виртуальный терминал, убедитесь, что ваше USB-устройство подключено, и попробуйте войти в систему, используя учётную запись пользователя, которую вы настраивали с помощью пары открытого/закрытого ключей. Если всё пойдёт по плану, пароль у вас не спросят: вместо этого вы окажетесь в системе под вашей учётной записью. Вы даже можете заметить огонёк на вашем USB, вспыхивающий, когда Pam_usb считывает публичный ключ. На экране вы должны увидеть следующее:
 
Переключитесь в виртуальный терминал, убедитесь, что ваше USB-устройство подключено, и попробуйте войти в систему, используя учётную запись пользователя, которую вы настраивали с помощью пары открытого/закрытого ключей. Если всё пойдёт по плану, пароль у вас не спросят: вместо этого вы окажетесь в системе под вашей учётной записью. Вы даже можете заметить огонёк на вашем USB, вспыхивающий, когда Pam_usb считывает публичный ключ. На экране вы должны увидеть следующее:
 +
 
  Authentication request for user graham from local console (/dev/tty2)
 
  Authentication request for user graham from local console (/dev/tty2)
 
  Access granted
 
  Access granted
Строка 203: Строка 162:
  
 
Ура! Вы только что сумели заставить работать USB-аутентификацию. Но что произойдёт, если вы потеряете свой USB-брелок? Вы не сможете войти в систему. Это катастрофа! Решение – добавить ещё одно правило в стек в конфигурационном файле PAM. Просто раскомментируйте строку с pam_unix2.so, и измените директиву для pam_usb на sufficient:
 
Ура! Вы только что сумели заставить работать USB-аутентификацию. Но что произойдёт, если вы потеряете свой USB-брелок? Вы не сможете войти в систему. Это катастрофа! Решение – добавить ещё одно правило в стек в конфигурационном файле PAM. Просто раскомментируйте строку с pam_unix2.so, и измените директиву для pam_usb на sufficient:
 +
 +
auth    sufficient    pam_usb.so
 +
auth    required      pam_unix2.so
 +
 +
 +
<!--
 
{|style="background-color:#c0c0ff;" cellpadding="3"
 
{|style="background-color:#c0c0ff;" cellpadding="3"
 
|auth
 
|auth
Строка 212: Строка 177:
 
|pam_unix2.so
 
|pam_unix2.so
 
|}
 
|}
 +
!-->
  
 
Как мы видели ранее, это означает, что если PAM сможет аутентифицировать пользователя только по USB-модулю, то так оно и будет. В противном случае процедура перекинется на нормальную аутентификацию по паролю с использованием pam_unix2.so. Старые версии PAM будут использовать pam_unix.so. (Это, вероятно, самое мудрое решение для тех, кто боится потерять свой USB-брелок).
 
Как мы видели ранее, это означает, что если PAM сможет аутентифицировать пользователя только по USB-модулю, то так оно и будет. В противном случае процедура перекинется на нормальную аутентификацию по паролю с использованием pam_unix2.so. Старые версии PAM будут использовать pam_unix.so. (Это, вероятно, самое мудрое решение для тех, кто боится потерять свой USB-брелок).
Строка 219: Строка 185:
  
 
Для этого просто измените sufficient для pam_usb снова на required, чтобы конфигурационный файл выглядел следующим образом:
 
Для этого просто измените sufficient для pam_usb снова на required, чтобы конфигурационный файл выглядел следующим образом:
 +
 +
auth    required    pam_usb.so
 +
auth    required    pam_unix2.so
 +
 +
<!--
 
{|style="background-color:#c0c0ff;" cellpadding="3"
 
{|style="background-color:#c0c0ff;" cellpadding="3"
 
|auth
 
|auth
Строка 228: Строка 199:
 
|pam_unix2.so
 
|pam_unix2.so
 
|}
 
|}
 +
!-->
  
Поздравляем – у вас есть работающая система USB-аутентификации, использующая PAM. Просто подойдите к вашей машине и вставьте USB-брелок – правда, круто? Но зачем останавливаться на достигнутом? Для лучшей интеграции с вашим рабочим столом следующий шаг – взять ту же самую процедуру, которую мы использовали для login, и сделать такие же изменения с другими сервисами, которые ваша система использует для аутентификации пользователей – хотя бы с графическим менеджером входа в систему GDM. Запуск утилит с привилегиями администратора через sudo – тоже хорошее применение для ваших свежеобретённых навыков. Просто сделайте такие же изменения в /etc/pam.d/sudo, какие мы делали в /etc/pam.d/login, и пользователи вашей системы смогут использовать sudo, только если подключен USB-брелок.
+
Поздравляем – у вас есть работающая система USB-аутентификации, использующая PAM. Просто подойдите к вашей машине и вставьте USB-брелок – правда, круто? Но зачем останавливаться на достигнутом? Для лучшей интеграции с вашим рабочим столом следующий шаг – взять ту же самую процедуру, которую мы использовали для login, и сделать такие же изменения с другими сервисами, которые ваша система использует для аутентификации пользователей – хотя бы с графическим менеджером входа в систему GDM. Запуск утилит с привилегиями администратора через sudo – тоже хорошее применение для ваших свежеобретённых навыков. Просто сделайте такие же изменения в '''/etc/pam.d/sudo''', какие мы делали в '''/etc/pam.d/login''', и пользователи вашей системы смогут использовать sudo, только если подключен USB-брелок.
  
 
У PAM куда больше возможностей, чем добавление нескольких дополнительных механизмов аутентификации. Теперь, когда вы вооружены идеями насчёт того, как создать собственный стек аутентификации и добавить произвольные модули, почему бы не построить супер-механизм аутентификации на базе той старой шляпы из фольги?
 
У PAM куда больше возможностей, чем добавление нескольких дополнительных механизмов аутентификации. Теперь, когда вы вооружены идеями насчёт того, как создать собственный стек аутентификации и добавить произвольные модули, почему бы не построить супер-механизм аутентификации на базе той старой шляпы из фольги?
 +
 +
[[Категория:Учебники]]
 +
[[Категория:Hardcore Linux]]
 +
[[Категория:Грэм Моррисон]]

Текущая версия на 12:14, 7 января 2009

Содержание

[править] PAM Аутентификация на заказ

Аутентификация пользователей – это не для новичков, но при грамотном применении PAM-модулей можно настроить довольно хитроумные схемы входа в систему – даже используя скромный USB-брелок. Грэм Моррисон покажет – как.

Большинство из нас считает аутентификацию пользователя само собой разумеющейся: вводим имя пользователя и пароль, жмём Enter, и всё. Но всякий раз, когда вы входите в свою систему – хоть через обычную консоль, хоть с помощью графического менеджера вроде GDM, хоть удалённо, используя SSH – существует фоновая система, проверяющая ваши полномочия, и почти всегда этой системой является PAM, как сокращённо именуются подключаемые модули аутентификации (Pluggable Authentication Modules). Я сказал «почти», потому что Slackware по умолчанию не задействует PAM – насколько мне известно, он один такой среди крупных дистрибутивов. Пользователи же SUSE, Fedora, Ubuntu и Mandriva могут использовать PAM прямо сейчас. Конкретно мы займемся на данном уроке вот чем: добавим новый модуль аутентификации, который позволит вам входить в систему, не используя ничего, кроме USB-брелка. Такой пример – лучший способ разобраться, как работает PAM и почему это такой замечательный инструмент. Несмотря на сложность этой темы и на тот факт, что вы все-таки читаете учебник для профессионалов, вы обнаружите, что настроить собственный модуль аутентификации с помощью PAM относительно просто. Мы пометили этот учебник «для профессионалов», так как будем иметь дело с аутентификацией пользователей. С PAM может быть очень сложно работать, и если вы что-то сделаете неправильно, последствия могут быть катастрофическими.

[править] Предостережение

Коль скоро вы соблюдаете обычную меру предосторожности, резервируя все редактируемые файлы, при испытании этого USB-проекта беспокоиться особо не о чем. Но всё будет немного иначе, если вы планируете использовать USB-аутентификацию в реальном окружении, как первую линию обороны от пользователей, пытающихся обольстить вашу систему с целью получения неавторизованного доступа. В этом случае единственное требование – убедитесь, что PAM настроен как надо. Нужно также ограничить физический доступ к машине и заблокировать все не в меру вольные сервисы, запущенные на вашей системе. Даже когда пользователи аутентифицируются исключительно при помощи USB-брелка, злоумышленник сможет получить административный доступ к вашей системе, просто нажав кнопку «Reset» и перегрузив ваш дистрибутив в безопасный режим (failsafe mode).

Если вы планируете использовать PAM, чтобы защитить свою систему таким способом, важно также иметь стратегию ограничения физического доступа к вашему компьютеру. Простое решение – запереть компьютер в защищённом помещении и подключить к USB-хабу, запертому в вашем столе. Так могут делать люди, желающие обезопасить свои драгоценные «USB-замки» для программной аутентификации, и вы можете это использовать для PAM-аутентификации. В любом случае, безопасность определяется самым слабым звеном в цепи.

[править] Шаг 1 – Зачем нужен PAM

Прежде чем зарываться в настройку PAM, стоит рассмотреть это приложение как таковое. Программа была разработана в Sun Microsystems в 1996 году, с целью навести порядок в широком спектре механизмов аутентификации, использовавшихся в начале 90-х.

Проблема тогда заключалась в том, что не существовало единого унифицированного интерфейса, используемого при аутентификации пользователей. Тем, кто разрабатывал инструменты, требующие входа (login), приходилось вручную связывать свое приложение с необходимым методом (или методами) аутентификации. Хороший пример – Linux-команда login, генерирующая приглашение ввести имя пользователя на виртуальных терминалах. До PAM login нужно было связывать с каждым механизмом аутентификации, угодным автору, а это могли быть столь несходные методы, как шифрованные пароли, биометрия и всевозможные смарт-карты. Разработчикам было нелегко заниматься сопровождением в этой ситуации. Если администратор решал изменить механизм аутентификации, нужно было перенастраивать все приложения, которые его использовали.

Вот почему появился PAM. PAM размещается между тем, что называется сервисами (в основном, login и другие программы «системного входа»), нуждающимися в механизме аутентификации, и самим механизмом. В сервис нужно только встроить поддержку PAM – и употреблять любой метод аутентификации, предусмотренный в PAM. Пока login использует PAM, разработчику больше ни о чем думать не нужно: это забота PAM, и если вам нужно изменить механизм аутентификации для login, ftp или su, PAM – единственное место, где это нужно делать.

[править] И аутентификация всей страны!

Как правило, файлы конфигурации PAM находятся в каталоге /etc/pam.d вашей файловой системы. Этот каталог содержит файлы конфигурации всех приложений с аутентификацией через PAM, обычно включающие записи для стандартных сервисов, например, gdm, xdm, cups и даже screensaver – почти всех, в которых требуется пароль.

Взглянув на любой конфигурационный файл PAM, вы увидите нечто подобное (взято из gdm в SUSE 10.1):

auth include common-auth account include common-account password include common-password session include common-session


Каждый столбец этого конфигурационного файла представляет одну из четырёх директив. Это тип интерфейса модуля (первый столбец), флаг управления (второй столбец), путь к модулю (третий столбец) и любые аргументы модуля (в примере gdm их нет, поэтому столбец пустой). Интерфейс модуля и сам имеет четыре варианта, каждый из которых показан в нашем примере – auth, account, password и session. Модули auth будут аутентифицировать пользователей, что обычно означает проверку соответствия имени пользователя и пароля. Затем идут модули account, проверяющие правильность учётной записи. Password, естественно, проверяет пароль, а session обеспечивает выполнение всего, что полагается сделать перед предоставлением сервиса пользователю, например, монтирование пользовательского домашнего или почтового каталога.

Наиболее важный столбец – второй, флаг управления; его-то мы и будем менять в нашем новом модуле, чтобы изменить требования аутентификации, когда вставлен USB-брелок. В нашем куске кода из конфигурационного файла gdm все четыре поля установлены в include. Это особый случай, поскольку ключевое слово include на самом деле указывает PAM направление к другому конфигурационному файлу в третьем поле (common-auth). Этот файл содержит общие правила, пригодные для различных сервисов. Содержимое файла login указывает туда же.

Открыв файл /etc/pam.d/common-auth, вы увидите нечто вроде следующего (если вы используете старую версию PAM, эта информация будет в файле gdm):

auth    required    pam_env.so
auth    required    pam_unix2.so

Когда пользователь входит в систему, модуль аутентификации передаёт сигнал к флагу управления практически тем же способом, как возвращают сигналы процессы и функции. Этот сигнал сообщает о том, что происходило, пока процес или функция исполнялась. Есть сигналы для «успеха» и «неудачи», а есть и сигналы для ошибок сервиса или оповещения, что учётная запись устарела. С новыми версиями PAM вы можете создавать собственные правила для любого из этих условий, это облегчает обработку исключений.

Приведённый выше фрагмент включает более типичный флаг управления – required. Он говорит PAM, что модуль auth обязан завершиться успешно. Менее строгий флаг управления – sufficient, означающий, что если аутентификация для этого модуля успешна, системе PAM не нужно продолжать аутентификацию какими-нибудь другими модулями, чтобы предоставить доступ. Другой общий флаг управления – optional, который, как подсказывает название, не критичен для предоставления доступа. Причина, почему существуют меняющиеся степени «успешности», заключается в том, что вы можете объединить модули вместе и проектировать аутентификацию на основе «успешности» отдельного модуля или стека из нескольких – именно то, как мы будем настраивать нашу аутентификацию по USB.

[править] Шаг 2 - Установка модуля USB

Модуль USB, который нам понадобится, разрабатывается отдельно от основного приложения PAM, и пока считается не завершенным, хотя на самом деле полностью функционален. Называется он Pam_usb, и его можно найти на нашем диске или на www.pamusb.org. Последняя версия выпущена в октябре 2005 года, но она работает с ядрами 2.6 и современными дистрибутивами.

Первый шаг – скачать исходный код с сайта Pam_usb. Сборка и инсталляция модуля очень просты: наберите make, затем – make install с правами root , а конфигурационного скрипта здесь нет. Будет установлена пара скриптов hotplug и создан каталог /etc/pam_usb. Кроме того, в /usr/bin будет установлен инструмент администрирования usbadm. Скрипт hotplug разработан для блокировки сеанса, когда извлекается USB-устройство, используемое для аутентификации.

[править] Сидеть! Место!

Очень важно, чтобы ваше устройство USB всегда обнаруживалось в одном и том же месте. Горячее подключение USB-устройств печально известно в Linux как ненадёжное, но многие из последних дистрибутивов, похоже, наконец-то заставят его работать. Сложность заключается в том, что модулю Pam_usb необходимо находить устройство USB в одной и той же точке монтирования, когда бы вы ни подключили его к машине.

К тому же, настоятельно рекомендуется, чтобы устройства монтировали себя сами (используя hotplug); в противном случае вы завязнете, если не сможете войти на машину и разобраться с хулиганящим USB-оборудованием. Я обнаружил, что и SUSE 10.1, и Ubuntu 6.06 работают без каких-либо дополнительных ухищрений. Современные дистрибутивы монтируют эти устройства согласно их идентификаторам, назначенным изготовителем и определяемым скриптом hotplug при опросе USB (вы можете сделать это сами, набрав lsusb). Когда вы сможете достоверно находить ваше устройство USB в файловой системе, вам потребуется передать эту информацию в usbadm; она автоматически создаст ключи, необходимые для шифрования, чтобы защитить вашу информацию, и скопирует все файлы конфигурации на их законные места в файловой системе и на USB-брелок.

(thumbnail)
Создание ключа шифрования DSA с помощью usbadm очень похоже на генерацию ключа с помощью GnuPG – и не удивительно, поскольку оба используют один и тот же вид шифрования.

Отданная вами команда должна выглядеть следующим образом – только измените имя пользователя и размещение вашего USB-устройства:

usbadm keygen /media/KINGSTON graham 1024

В этом примере /media/KINGSTON – точка монтирования USB-брелка, graham – имя пользователя, а 1024 – размер DSA-ключа шифрования, который должен сгенерироваться. Фактически эта команда размещает открытый ключ в .auth в пользовательском каталоге, а закрытый ключ в .auth на USB-устройстве. Тем, кто знаком с шифрованием парным ключом, известно, что неважно, кому доступен публичный ключ – но каждый владелец копии закрытого ключа сможет пройти аутентификацию и войти на вашу машину. Другими словами, любая личность, присвоившая ваше USB-устройство...

[править] Укрепляем USB

Конечно, вы наверняка уже обнаружили большую проблему. Запросто можно скопировать приватный ключ на другое устройство и использовать его для аутентификации. Это основное отличие между общим USB-устройством, используемым с модулем Pam_usb, и блокирующей проприетарной смарт-картой, которая запирает закрытый ключ на аппаратном уровне.

Есть два решения этой проблемы. Первая – держать ваш закрытый ключ на USB-устройстве с определенным серийным номером. Модуль Pam_usb может затем проверять этот серийный номер и убеждаться, что приватный ключ не был скопирован.

Если ваше USB-устройство снабжено встроенным серийным номером, вы можете запросить его и добавить его к модулю, набрав usbadm addserial, или добавить его вручную, введя usbadm addserial 12345. Серийный номер добавляется к /etc/pam_usb/serials.conf. Использовать серийные номера таким способом не совсем безопасно – отчасти потому, что программисту относительно легко раскрыть серийный номер, хранящийся в вашем устройстве, а отчасти потому, что так мало USB-брелков действительно снабжены серийный номер. Итак, подумаем над альтернативным решением.

[править] Двойная защита

Каждый отдельный метод аутентификации называется токеном, и каждый имеет сильные и слабые стороны. В случае с приватным ключом, размещённым на USB-брелке, слабостью, очевидно, является безопасность ключа и серьёзное неудобство в случае потери USB-брелка. Аналогично, основная слабость парольной аутентификации – атака подбором (brute force): взломщик может пройтись по тысячам хорошо известных комбинаций символов в надежде угадать ваш пароль.

Решение, оно же моя альтернатива использованию серийного номера – двухкаскадная аутентификация, задействующая два различных метода одновременно. Здесь безопасность USB-брелка должна играть важную роль. Комбинация приватного ключа, размещённого на USB-брелке, и обычной аутентификации по паролю предоставляет сильный уровень системной безопасности и защищает от наиболее общей атаки на безопасность: подбора пароля. При использовании двух методов аутентификации, даже если пароль будет угадан, потенциальному злоумышленнику всё-таки не обойтись без закрытого ключа с вашего USB-брелка. В PAM это означает стековую аутентификацию, и на следующей странице я покажу вам, как её настроить.

[править] Шаг 3 - Ваша конфигурация PAM

Теперь вникнем в детали добавления нового метода PAM-аутентификации. Для начала, нам нужно выбрать сервис, который мы хотим запереть с помощью нашего USB-ключа. Вышеупомянутый login – хорошая стартовая точка, отчасти потому, что его легко использовать, а отчасти – потому что не будет большой беды, если вы что-то заблокируете (если, конечно, это не удалённая система, и login – не единственный способ подключиться к ней). Скрипт конфигурации PAM для login можно найти в /etc/pam.d/login; откройте его в своём любимом редакторе (или в нелюбимом, если вам нужно встряхнуться).

(thumbnail)
Это – рабочий файл конфигурации PAM из SUSE 10.1, модифицированный добавкой модуля Pam_usb.

Нам нужно проверить, что Pam_usb работает, и простейший способ проверки – убедиться, что это единственный метод, требуемый для входа в систему, для чего мы закомментируем строку, включающую auth required pam_unix2.so. Если такой строки нет, вероятно, найдётся строка с директивой include, указывающей на файл с именем common-auth. Просмотрите содержимое этого файла, и найдете auth required pam_unix2.so – но здесь это закомментировать было бы глупо, потому что тогда любой другой сервис, включающий common-auth, не сможет выполнить аутентификацию и блокирует вашу систему.

Вместо этого скопируйте содержимое из common-auth в login, и закомментируйте обе строки – include, указывающую на этот файл, и строку, заканчивающуюся на pam_unix2.so. Затем добавьте auth require pam_usb.so; получится нечто вроде

auth     required    pam_usb.so
auth     required    pam_env.so
#auth    required    pam_unix2.so
#auth    include     common-auth


Переключитесь в виртуальный терминал, убедитесь, что ваше USB-устройство подключено, и попробуйте войти в систему, используя учётную запись пользователя, которую вы настраивали с помощью пары открытого/закрытого ключей. Если всё пойдёт по плану, пароль у вас не спросят: вместо этого вы окажетесь в системе под вашей учётной записью. Вы даже можете заметить огонёк на вашем USB, вспыхивающий, когда Pam_usb считывает публичный ключ. На экране вы должны увидеть следующее:

Authentication request for user graham from local console (/dev/tty2)
Access granted

Это сообщение отображается всякий раз, когда модуль Pam_usb выполняет свою работу. Если вы извлечёте ваше USB-устройство, то обнаружите, что обратно вас не пускают, и отображается предупреждение. Попробуйте подключить ваш USB-брелок и попытаться ещё раз.

Ура! Вы только что сумели заставить работать USB-аутентификацию. Но что произойдёт, если вы потеряете свой USB-брелок? Вы не сможете войти в систему. Это катастрофа! Решение – добавить ещё одно правило в стек в конфигурационном файле PAM. Просто раскомментируйте строку с pam_unix2.so, и измените директиву для pam_usb на sufficient:

auth    sufficient    pam_usb.so
auth    required      pam_unix2.so


Как мы видели ранее, это означает, что если PAM сможет аутентифицировать пользователя только по USB-модулю, то так оно и будет. В противном случае процедура перекинется на нормальную аутентификацию по паролю с использованием pam_unix2.so. Старые версии PAM будут использовать pam_unix.so. (Это, вероятно, самое мудрое решение для тех, кто боится потерять свой USB-брелок).

[править] Пароль про запас

Данный способ использования Pam_usb, несомненно, предлагает приемлемый уровень безопасности для домашней машины, и удобен тем, что не требует пароля – но если вы действительно бережёте свою учётную запись, вам нужен иной уровень безопасности. Простейший способ сделать это – настроить требование как пароля, так и USB-аутентификации одновременно, пресекая подбор вашего пароля и копирование ключа с USB-брелка.

Для этого просто измените sufficient для pam_usb снова на required, чтобы конфигурационный файл выглядел следующим образом:

auth    required    pam_usb.so
auth    required    pam_unix2.so


Поздравляем – у вас есть работающая система USB-аутентификации, использующая PAM. Просто подойдите к вашей машине и вставьте USB-брелок – правда, круто? Но зачем останавливаться на достигнутом? Для лучшей интеграции с вашим рабочим столом следующий шаг – взять ту же самую процедуру, которую мы использовали для login, и сделать такие же изменения с другими сервисами, которые ваша система использует для аутентификации пользователей – хотя бы с графическим менеджером входа в систему GDM. Запуск утилит с привилегиями администратора через sudo – тоже хорошее применение для ваших свежеобретённых навыков. Просто сделайте такие же изменения в /etc/pam.d/sudo, какие мы делали в /etc/pam.d/login, и пользователи вашей системы смогут использовать sudo, только если подключен USB-брелок.

У PAM куда больше возможностей, чем добавление нескольких дополнительных механизмов аутентификации. Теперь, когда вы вооружены идеями насчёт того, как создать собственный стек аутентификации и добавить произвольные модули, почему бы не построить супер-механизм аутентификации на базе той старой шляпы из фольги?

Персональные инструменты
купить
подписаться
Яндекс.Метрика