Модуль 10. Система аутентификации PAM и управление правами SUDO

Введение

Из этого модуля вы узнаете, почему нельзя «сидеть под рутом» и как именно работают утилиты sudo и su, позволяющие временно перейти в режим бога. Мы вскроем внутреннее устройство PAM-стека и даже пришьем к своему франкенштейну парочку новых PAM-модулей. В ходе экспериментов ни один сисадмин не пострадает.

Управление привилегиями в Linux

Установщик операционной системы Linux всегда создает учетную запись суперпользователя с именем root (от англ. корень), идентификатор которой равен нулю. Но это не просто привилегированный пользователь, как встроенный администратор Windows с RID 500, которого при большом желании можно и удалить. Пользователь root по своей сути является аналогом учетной записи SYSTEM. В Linux от имени root стартует подсистема инициализации /sbin/init и запускаются все остальные системные процессы, поэтому, если удалить эту учетную запись из локальной базы пользователей /etc/passwd, то система просто не взлетит.

Суперпользователь root получает свою суперсилу исключительно потому, что его идентификатор UID равен 0. Однако с версии ядра 2.2 стало возможным делегировать эти полномочия через так называемые привилегии (capabilities). Поэтому теперь root может быть не единственным пользователем с суперсилой, но в пантеоне богов Linux имя суперпользователя навечно закрепилось именно за ним.

Например, для того чтобы пользователь localadmin мог произвольно менять UID/GID любым файлам и папкам, ему нужно делегировать привилегию CAP_CHOWN. Сделать это можно с помощью оснастки «Управление политикой безопасности». Просто выберите учетную запись localadmin в колонке слева и на вкладке «Привилегии» в основной части окна установите флажок напротив «CAP_CHOWN», см. рис. 42.

рис. 42 Делегирование привилегий пользователю

В обычных линуксах привилегии пользователей задаются в файле /etc/security/capability.conf, а за их применение отвечает модуль pam_cap.so. В Astra Linux реализована собственная подсистема безопасности PARSEC, поэтому:

• кроме обычных Linux-привилегий есть еще привилегии Parsec,

• все настройки для пользователя localadmin с UID=1000 записываются в файл /etc/parsec/capdb/1000,

• а установку наследуемых привилегий на процесс, в котором запускается оболочка пользователя, выполняет модуль pam_parsec_cap.

Чтобы изменения вступили в силу, нужно перезайти в систему, но после этого для пользователя будет включен режим бога, по крайней мере, в части использования chown.

Привилегии стали одним из существенных улучшений системы безопасности Linux. А до их появления системным администраторам иногда приходилось создавать для root так называемые псевдонимы — это когда несколько пользователей используют один и тот же идентификатор 0 (см. ключ --non-unique утилиты useradd). Но если вы спросите любого ИБэшника, то он вам сразу и от души втолкует, что лучше так не делать никогда, никогда, никогда. Данная практика считается настолько порочной, что об этом ящике пандоры теперь предпочитают даже не вспоминать.

И, кстати, столь же порочными практиками считают стикеры с паролями на мониторе и вход в систему из-под рута. Но если со стикерами все очевидно, то во втором случае угроза состоит в том, что все пользовательские приложения будут иметь привилегии суперпользователя, и через малейшую уязвимость в Firefox, LibreOffice или CS:GO злоумышленники смогут захватить всю вашу систему целиком.

Из всего вышесказанного следует, что, когда вам самим потребуется выполнить какое-то действие с повышенными привилегиями или нужно будет предоставить такое право другим пользователям, следует использовать только правильные инструменты, такие как утилиты su и sudo.

Утилита su

В системе Linux запустить что-то из-под другого пользователя можно, например, с помощью утилиты su (от англ. Substitute User - подменить пользователя), которая похожа на «Run as administrator» или «Run as different user» в Windows.

По умолчанию утилита запускает оболочку из-под указанного пользователя, но с помощью ключей -c или --command можно определить строго ограниченный набор команд. Для указания имени целевого пользователя следует использовать длинный ключ --login (su -login username), короткий ключ -l (su –l username) или не указывать имя ключа вовсе, обозначив его символом дефиса (su - username).

Если имя пользователя не задать явно, то будет подразумеваться, что мы хотим запустить оболочку от имени root, поэтому утилита будет ожидать ввод пароля от учетной записи суперпользователя (команда su - эквивалентна команде su - root).

В использовании утилиты su есть еще один существенный нюанс. Если вы указываете ключ login или обозначаете его хотя бы дефисом, то оболочка запускается в окружении целевого пользователя так же, как будто он выполнил полноценный интерактивный вход в систему. Если же вы запустите утилиту su без ключа (например, su или su localadmin), то все переменные, за исключением PATH, USER и некоторых других, будут унаследованы от пользователя, который запустил утилиту su.

Продемонстрируем это на примере переменной myuser_var. Определяем в окружении пользователя myuser переменную myuser_var:

myuser@astra:~$ export myuser_var=test_value
myuser@astra:~$ echo $myuser_var
test_value

Проверяем, что при запуске su без ключа переменная доступна:

myuser@astra:~$ su localadmin -c 'echo myuser_var=$myuser_var'
Пароль:
myuser_var=test_value

Проверяем, что при запуске su с обозначением ключа переменная не доступна:

myuser@astra:~$ su - localadmin -c 'echo myuser_var=$myuser_var'
Пароль:
myuser_var=

Примечание

Переменные окружения играют очень важную роль, т.к. с их помощью может выполняться настройка системных утилит и клиентских приложений.

Например, если выполнить в терминале «export KRB5_TRACE=/dev/stdout», то это заставит утилиту kinit на доменных компьютерах отображать полную трассировку всех вызовов.

Утилита su всем хороша, за исключением следующих моментов:

• Для возможности использования утилиты su пользователю нужно предоставить пароль от привилегированной учетной записи, а в соответствии с лучшими практиками интерактивный вход из-под рута заблокирован, и пароля у этой учетной записи нет. Внезапно, правда! :)

• Учитывая, что для использования утилиты su пользователю предоставляется пароль от привилегированной учетной записи, его полномочия невозможно ограничить каким-либо перечнем команд. Он сможет выполнить в системе из-под этого пользователя все, что угодно.

Ввиду указанных причин более продвинутым инструментом следует считать утилиту sudo.

Утилита sudo

В результате развития идей гранулярного делегирования полномочий на выполнение команд появилась утилита sudo (от англ. Substitute User and DO - подменить пользователя и выполнить).

Утилита sudo позволяет системному администратору делегировать полномочия конкретным пользователям на запуск конкретных команд от имени других конкретных пользователей. И все это с журналированием выполняемых действий. Настройки для утилиты sudo задаются в конфигурационном файле /etc/sudoers и называются правилами SUDO. Дополнительные настройки могут находиться так же в папке /etc/sudoers.d/.

Синтаксис команды SUDO

Команда sudo <команда [опции]> позволяет выполнить команду от имени суперпользователя, например, sudo touch new_file.

localadmin@astra:~$ sudo touch new_file
[sudo] пароль для localadmin:
localadmin@astra:~$ ls -l new_file
-rw-r--r-- 1 root root 0 сен 18 10:14 new_file

Если необходимо выполнить не одну команду, а несколько, то можно запустить интерактивный режим работы sudo, использовав опцию -i (длинный ключ --login) sudo -i. Для выхода из интерактивного режима необходимо ввести команду exit.

localadmin@astra:~$ sudo -i
root@astra:~# chmod +x /home/localadmin/new_file
root@astra:~# chown localadmin /home/localadmin/new_file
root@astra:~# exit
выход
localadmin@astra:~$ ls -l new_file
-rwxr-xr-x 1 localadmin root 0 сен 18 10:14 new_file

По умолчанию утилита sudo выполняет команду из-под суперпользователя root, но с помощью ключа -u вы можете указать и любого другого пользователя системы:

localadmin@astra:/etc$ sudo -u myuser id
uid=1001(myuser) gid=1002(myuser)
группы=1002(myuser),20(dialout),24(cdrom),25(floppy),29(audio),44(video),46(plugdev),100(users)

Полное описание ключей команды вы найдете в справке sudo (8), которую можно вызвать командой man 8 sudo.

Примечание

Возможности утилиты sudo настолько прекрасны, что Microsoft реализовали нечто очень похожее https://github.com/microsoft/sudo. Будем посмотреть, как этот проект станет развиваться дальше.

Правила SUDO

Правила SUDO создают дополнительный слой авторизации, позволяя делегировать конкретным пользователям право выполнения отдельных команд с повышенными привилегиями. Локальные настройки утилиты sudo находятся в файле /etc/sudoers, который назван так потому, что пользователей, кому разрешено повышать привилегии с помощью утилиты sudo, называют sudo enabled users или кратко sudoers.

В файле могут быть строки трех типов: параметры по умолчанию, псевдонимы (алиасы, именованные списки или проще переменные) и сами правила. Синтаксис правил представлен на рисунке ниже:

рис. 43 Синтаксис правил SUDO

Правила могут быть как разрешающими, так и запрещающими, но по умолчанию считается, что прав на выполнение команд через sudo ни у кого нет. Для первых четырех компонентов правил следует определить область действия одним из двух способов:

• Любой субъект (ALL) — правило будет распространяться на все субъекты данного вида.

• Указанные субъекты — правило будет распространяться только на указанный перечень субъектов данного вида. Если требуется задать несколько значений, элементы списка должны быть разделены запятой.

Для упрощения работы с большими списками синтаксис файла позволяет задавать именованные списки или так называемые алиасы. Для удобства настройки синтаксис именованных списков позволяет также исключать из них отдельные значения.

Рассмотрим внимательнее каждый компонент правила:

1. Пользователи и группы пользователей, которым разрешен запуск команд в рамках данного правила. Перед именем группы следует указывать символ процента.

2. Хосты, на которых разрешен запуск команд. Это может быть имя компьютера или его IP-адрес. Параметр полезен, если один и тот же файл копируется на несколько хостов сразу.

3. Пользователи, от имени которых разрешен запуск команд. При выполнении команды через sudo по умолчанию предполагается, что команда запускается от имени root, но можно указать имя пользователя в явном виде с помощью ключа -u, и данный компонент правила позволяет ограничить перечень допустимых значений.

4. Первичные группы, в контексте которых разрешен запуск команд. По умолчанию используется первичная группа пользователя, от имени которого выполняется команда, но группу можно указать явно с помощью ключа -g. Данное значение проявляет себя, когда выполняются команды, которые создают новые файлы и папки, например, touch или mkdir. Этот параметр не является обязательным.

5. Параметры, с которыми будет выполнена утилита sudo, позволяют изменить поведение утилиты sudo. Например, с помощью NOPASSWD можно отключить запрос пароля. Этот параметр не является обязательным. Полный перечень доступных значений: EXEC, NOEXEC, FOLLOW, NOFOLLOW, LOG_INPUT, NOLOG_INPUT, LOG_OUTPUT, NOLOG_OUTPUT, MAIL, NOMAIL, PASSWD, NOPASSWD, SETENV и NOSETENV. О значении параметров можно посмотреть в справке man sudoers.

6. Команды, которые разрешено запускать в рамках этого правила. Это должен быть полный путь к исполняемому файлу. В конце строки можно указать допустимые параметры вызова.

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

В правилах SUDO можно использовать не только конкретные значения, но и шаблоны. В Astra Linux до версии 1.7.4 включительно используется проверенная версия sudo 1.8.x, в которой доступны только шаблоны в стиле shell, обработка которых выполняется через функции glob и fnmatch. С версии sudo 1.9.10 появится возможность использовать полноценные регулярные выражения.

В шаблонах можно использовать следующие символы подстановки (wildcards) или так называемые метасимволы:

• «?» – соответствует одному любому символу.

• «*» – соответствует любому количеству любых символов, в том числе и пустой строке. С использованием символа * следует быть крайне осторожным.

• «\» – позволяет экранировать спецсимволы, т.е. отключить их управляющую функцию. Используется, когда нужен знак вопроса, звездочки, двоеточия и др.

• «»»» (две подряд идущие двойные кавычки) – соответствует пустой строке. Если пустая строка указана в качестве единственного параметра команды, то эта команда может быть выполнена только без параметров.

• […] – соответствует одному символу из указанного диапазона, например:

  • [abc] соответствует символу a, b или c;

  • [a-z] соответствует строчному символу латинского алфавита;

  • [[\:lower\:]] соответствует строчному символу латинского алфавита, но диапазон задан с помощью именованного класса символов (named character classes), полный перечень которых включает alnum, alpha, blank, cntrl, digit, graph, lower, print, punct, space, upper, xdigit.

• [!…] – восклицательный знак в начале диапазона позволяет инвертировать набор символов, т.е. шаблон соответствует любому символу, который не входит в указанный диапазон.

Механизм работы правил SUDO

Как уже было сказано, настройки утилиты sudo определяются содержимым файла /etc/sudoers. В этом файле находится также инструкция #includedir /etc/sudoers.d, которая включает содержимое дополнительных файлов из указанной директории. Инструкция начинается с символа решетки # как обычный комментарий, но комментарием не является, что может ввести в заблуждение. Сделано это так из соображений обратной совместимости, т.к. инструкции include и includedir были добавлены значительно позже, в 2004 и 2017 годах соответственно. С версии 1.9.1 появится возможность использовать символ @ собачки вместо решетки, что уменьшит путаницу.

В начале файла вы найдете предупреждение о том, что редактировать правила sudo напрямую не рекомендуется и лучше использовать утилиту visudo. Указанная утилита откроет файл в nano и обеспечит проверку синтаксиса перед сохранением изменений. Если вам ближе vi или mcedit. Вы можете заменить редактор по умолчанию:

localadmin@astra:~$ sudo update-alternatives --config editor
[sudo] пароль для localadmin:
Есть 4 варианта для альтернативы editor (предоставляет /usr/bin/editor).

  Выбор   Путь            Приор Состояние
------------------------------------------------------------
* 0            /bin/nano            40        автоматический режим
  1            /bin/nano            40        ручной режим
  2            /usr/bin/mcedit      25        ручной режим
  3            /usr/bin/vim.basic   30        ручной режим
  4            /usr/bin/vim.tiny    15        ручной режим

Press <enter> to keep the current choice[*], or type selection number: 0

Ниже представлено содержимое файла /etc/sudoers по умолчанию (без внесенных после установки системы изменений)

localadmin@astra:~$ sudo cat /etc/sudoers

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Defaults        !lecture

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d
%astra-admin    ALL=(ALL:ALL) ALL

В файле по умолчанию присутствуют несколько параметров:

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

• Параметр mail_badpass – предписывает системе отправлять уведомления о неудачных попытках ввода пароля при выполнении команды sudo. Предполагается доставка в локальный почтовый ящик /var/mail/root.

• Параметр secure_path – позволяет задать список каталогов, в которых будет выполняться поиск запускаемых через sudo утилит, когда не указан полный путь к файлу. Это исключает запуск вредоносных приложений с повышенными привилегиями.

• Параметр lecture – позволяет определить, как часто будет выводиться предупреждение пользователю о том, что следует с осторожностью использовать команду sudo, и возможность указать специальный файл, текст которого будет выводиться (lecture_file`).

Рассмотрим правила, представленные в файле /etc/sudoers сразу после установки операционной системы:

• Правило «root ALL=(ALL:ALL) ALL» означает, что пользователь root может на любом хосте от имени любого пользователя и в контексте любой первичной группы выполнить любую команду.

• Правило «%sudo ALL=(ALL:ALL) ALL» означает то же самое для группы sudo.

• Правило «%astra-admin ALL=(ALL:ALL) ALL» означает то же самое для группы astra-admin.

Внимание

На компьютерах в домене пользователь admin автоматически вносится в список участников локальной группы astra-admin, за счет чего получает право на выполнение команд от имени суперпользователя через утилиту sudo.

Управление правилами SUDO

Для примера возьмем такую задачу: у нас есть два пользователя user1 и user2, которым необходимо делегировать право на выполнение команды ls от имени суперпользователя, например, для просмотра домашних каталогов других пользователей.

1. Запустим утилиту sudo visudo для редактирования файла /etc/sudoers.

2. Добавим в раздел «User aliases» псевдоним для пользователей user1 и user2 GROUPAUDITORS:

User_Alias GROUPAUDITORS = user1 user2

3. Добавим в раздел «Cmnd_aliases» псевдоним AUDIT для команды ls -la /home/*:

Cmnd_Alias AUDIT = /usr/bin/ls -la /home/*

4. И добавим в конец файла строку, разрешающую группе пользователей GROUPAUDITORS запускать команду AUDIT на локальной машине:

GROUPAUDITORS astra = AUDIT

Вот как должен выглядеть файл /etc/sudoers:

# User alias specification
User_Alias    GROUPAUDITORS=user1,user2

# Cmnd alias specification
Cmnd_Alias    AUDIT=/usr/bin/ls -la /home/*

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo    ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d
%astra-admin    ALL=(ALL:ALL) ALL
GROUPAUDITORS    astra=AUDIT

Воспользуемся командой su - user1 и проверим, работает ли наше правило для пользователя user1 sudo ls -la /home/user2.

Откроем оболочку из-под пользователя user1 и убедимся, что прав на чтение каталогов других пользователей у нас нет:

localadmin@astra:~$ su - user1
Пароль:
user1@astra:~$ ls /home/user2/
ls: невозможно открыть каталог '/home/user2/': Отказано в доступе

Выполним то же самое из-под sudo, но без ключей, доступа быть не должно:

user1@astra:~$ sudo ls /home/user2/
[sudo] пароль для user1:
Sorry, user user1 is not allowed to execute '/usr/bin/ls /home/user2/' as root on astra.

Выполним команду с правильным набором ключей, доступ должен быть:

user1@astra:~$ sudo ls -la /home/user2/
[sudo] пароль для user1:
итого 28
drwx------ 3 user2 user2 4096 сен 18 11:22 .
drwxr-xr-x 8 root  root  4096 июл 26 10:38 ..
-rw------- 1 user2 user2    5 сен 18 11:22 .bash_history
-rw-r--r-- 1 user2 user2  220 сен 16  2020 .bash_logout
...
user1@astra:~$ exit
выход

Как видим, при обращении без sudo мы получили отказ, так как у пользователя user1 нет прав на домашний каталог пользователя user2.

При попытке выполнить команду без параметров мы получили отказ, т.к. такая команда не попадает под заданные правила.

И только в третий раз, когда мы запустили sudo ls -la /home/user2/, система разрешила выполнить эту команду из-под суперпользователя и вывела нам результат её выполнения.

Отладка правил SUDO

Список правил пользователя

Результирующий набор правил SUDO для текущего пользователя можно вывести на экран с помощью ключа -l (--list):

localadmin@astra:~$ sudo -l
[sudo] пароль для localadmin:
Matching Defaults entries for localadmin on astra:
   env_reset, mail_badpass,
   secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
   !lecture,
   secure_path=/usr/lib/parsec/bin\:/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User localadmin may run the following commands on astra:
   (ALL : ALL) ALL

Результирующий набор правил SUDO для конкретного пользователя можно узнать вызовом на целевой машине команды sudo с ключами -l и -U:

localadmin@astra:~$ sudo -l -U user1
Matching Defaults entries for user1 on astra:
   env_reset, mail_badpass,
   secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
   !lecture,
   secure_path=/usr/lib/parsec/bin\:/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User user1 may run the following commands on astra:
   (root) /usr/bin/ls -la /home/*

Журналирование sudo

Sudo имеет три варианта журналирования:

• Кто что запускал – /var/log/auth.log

• Полные журналы сессий – sudoreplay

• Журнал отладки sudo – debug

Файл журнала /var/log/auth.log

В журнале /var/log/auth.log заносится информация вида:

date hostname progname: username : TTY=ttyname ; PWD=cwd ;
USER=runasuser ; GROUP=runasgroup ; TSID=logid ; ENV=env_vars
COMMAND=command

Например:

Sep 26 10:27:50 astra sudo[17629]: localadmin : TTY=pts/3 ;
PWD=/home/localadmin ; USER=root ; COMMAND=/usr/local/bin/tail /var/log/auth.log

Полные журналы сессий

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

Для включения записи сессий sudo необходимо создать директорию /var/log/sudo-io с правами 750 sudo mkdir -m 750 /var/log/sudo-io и отредактировать файл /etc/sudoers, добавив 3 строки:

Defaults log_output
Defaults!/usr/bin/sudoreplay !log_output
Defaults!/sbin/reboot !log_output

После этого начнется запись сеансов работы и командой sudo sudoreplay -l можно просматривать эти сеансы.

localadmin@astra:~$ sudo sudoreplay -l
Сен 26 10:50:17 2024 : localadmin : TTY=/dev/pts/3 ;
CWD=/home/localadmin ; USER=root ; TSID=000001 ;
COMMAND=/usr/local/bin/ls -l
Сен 26 10:50:51 2024 : localadmin : TTY=/dev/pts/3 ;
CWD=/home/localadmin ; USER=root ; TSID=000002 ;
COMMAND=/usr/local/bin/cat /etc/sudoers

Полный список опций доступен в man sudoreplay.

Журнал отладки sudo

Журнал отладки позволяет отследить как sudo обрабатывает ваши политики. Для включения журналирования в режиме debug требуется создать файл /etc/sudo.conf.

Синтаксис файла состоит из ключевого слова Debug, за которым следует имя программы или плагина, подсистема для дебага и список флагов отладки, разделенных запятыми.

Debug sudo /var/log/sudo_debug all@warn

Поддерживаются следующие флаги (приоритеты) отладки в порядке уменьшения важности: crit, err, warn, notice, diag, info, trace и debug. Каждый приоритет также включает все приоритеты выше него. Например, приоритет notice будет включать отладочные сообщения, зарегистрированные на уровне notice и выше.

Подсистемы для дебага:

• all - matches every subsystem

• auth - user authentication

• defaults - sudoers file Defaults settings

• env - environment handling

• logging - logging support

• match - matching of users, groups, hosts, and netgroups in the sudoers file

• netif - network interface handling

• parser - sudoers file parsing

• perms - permission setting

• etc…

Например, создадим файл /etc/sudo.conf со следующим содержимым:

Debug sudo /var/log/sudo_debug.log all@debug
Debug sudoers.so /var/log/sudo_debug.log all@debug

localadmin@astra:~$ cat /etc/sudo.conf
Debug sudo /var/log/sudo_debug.log all@debug
Debug sudoers.so /var/log/sudo_debug.log all@debug

В файле /var/log/sudo_debug.log будет представлена информация о пользователе и среде окружения в момент запуска команды sudo. На один вызов sudo будет создано более 5 тыс. строк журнала, включая информацию о настройках и информацию о пользователе:

sudo[24829] settings: progname=sudo
sudo[24829] settings: network_addrs=10.0.2.15/255.255.255.0
fe80::a00:27ff:fe19:4a3a/ffff:ffff:ffff:ffff::
sudo[24829] settings: plugin_dir=/usr/lib/sudo/
sudo[24829] settings: plugin_path=/usr/lib/sudo/sudoers.so
. . .
sudo[24829] user_info: user=localadmin
sudo[24829] user_info: pid=24829
sudo[24829] user_info: ppid=23717
sudo[24829] user_info: pgid=24829
sudo[24829] user_info: tcpgid=24829
sudo[24829] user_info: sid=23717
sudo[24829] user_info: uid=1000
sudo[24829] user_info: euid=0
sudo[24829] user_info: gid=1000
sudo[24829] user_info: egid=1000
sudo[24829] user_info: groups=24,25,29,30,44,46,109,113,114,333,1000,1001
sudo[24829] user_info: umask=022
sudo[24829] user_info: cwd=/home/localadmin
sudo[24829] user_info: tty=/dev/pts/4
sudo[24829] user_info: host=astra
sudo[24829] user_info: lines=35
sudo[24829] user_info: cols=88

После сбора журнала, лучше отключить режим отладки, закомментировав строки в файле /etc/sudo.conf.

localadmin@astra:~$ cat /etc/sudo.conf
#Debug sudo /var/log/sudo_debug.log all@debug
#Debug sudoers.so /var/log/sudo_debug.log all@debug

Лучшие практики

Ниже представлено несколько лучших практик при управлении правилами SUDO.

Будьте осторожны с символами подстановки

Символ «звездочки» в правилах SUDO следует использовать крайне осторожно, так как ошибки в его использовании могут привести к предоставлению несанкционированного доступа.

Допустим, администратору нужно было предоставить сотруднику доступ на чтение журналов messages, и он создал следующее правило:

localadmin@astra:~$ sudo grep user3 /etc/sudoers
user3      ALL=(ALL:ALL) NOPASSWD :        /usr/bin/cat /var/log/messages

На первый взгляд все правильно, и пользователь сможет получить доступ к журналам:

localadmin@astra:~$ su - user3
Пароль:
user3@astra:~$ cat /var/log/messages | head -n 2
cat: /var/log/messages: Отказано в доступе
user3@astra:~$ sudo cat /var/log/messages | head -n 2
Sep 17 00:00:36 astra syslog-ng[25203]: The current log file has a
mismatching size/inode information, restarting from the beginning;
state='affile_sd_curpos(/var/log/cups/access_log)',
stored_inode='407048', cur_file_inode='406780', stored_size='0',
cur_file_size='0', raw_stream_pos='134091'
Sep 17 00:00:36 astra syslog-ng[25203]: Configuration reload request
received, reloading configuration;
user3@astra:~$ sudo cat /var/log/messages.1 | head -n 2
Sep 10 00:00:53 astra syslog-ng[27895]: Error initiating reload,
reload is already ongoing;
Sep 10 00:00:53 astra syslog-ng[27895]: The current log file has a
mismatching size/inode information, restarting from the beginning;
state='affile_sd_curpos(/var/log/cups/access_log)',
stored_inode='406760', cur_file_inode='406666', stored_size='0',
cur_file_size='0', raw_stream_pos='67158'

Но утилита cat называется так от слова concatenate (сцеплять), и на самом деле она позволяет объединять в один поток содержимое сразу нескольких файлов, поэтому никто не помешает пользователю добавить к журналу messages содержимое файла shadow, чтобы увидеть пароли:

user3@astra:~$ sudo cat /var/log/messages /etc/shadow | tail -n 2
user2:$gost12512hash$vs18/gLTU.BNZfhz$Gby5XxXNbMz4Zhb6Rg7Uzf8tCykTWl0ynLCYsdJ.9CY0nurmkY
zl0SzizoOr.Ex07pdSO402vCQHnt.wGKFnF.:19564:0:99999:7:::
user3:$gost12512hash$3zJkoCuxXSfG.CaT$ZyRoq2N4Roagxeb9u83doUVEml0tkFwJUJk6qePyqGSW0ZpJLi
wdeDuD358j6lkTkfYChDdeF.9rKJEQevUcU1:19564:0:99999:7:::

Конкретно в этом случае для предотвращения нежелательного поведения утилиты sudo в шаблон следует добавить еще одну команду, которая будет запрещать вызов команды cat с пробелами в параметре:

user3      ALL=(ALL:ALL) NOPASSWD :        /usr/bin/cat /var/log/messages*, !/usr/bin/cat /var/log/messages* *

Не разрешайте использование редактора vi

Работая в приложении vi, пользователь может не только редактировать текст, но и запускать команды оболочки, что дает значительные преимущества. Например, если в процессе редактирования файла конфигурации потребуется ввести точный путь к какому-то сертификату, пользователь сможет выполнить команду :shell, чтобы провалиться в оболочку и стандартными командами cd и ls уточнить необходимую информацию, а затем командой exit вернуться к редактированию файла.

Вместе с тем, такая реализация утилиты делает крайне опасным использование этого редактора вместе с правилами SUDO. Допустим, администратору нужно было предоставить сотруднику право на редактирование файла ldap.conf, и он создал следующее правило:

localadmin@astra:~$ sudo cat /etc/sudoers | grep user3
user3      ALL=(ALL:ALL) NOPASSWD :        /usr/bin/vi /etc/ldap/ldap.conf

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

localadmin@astra:~$ su - user3
Пароль:
user3@astra:~$ sudo vi /etc/ldap/ldap.conf
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
. . .
:shell

После выполнения команды :shell совершается уязвимость, и мы получаем доступ суперпользователя:

root@astra:/home/user3# cat /etc/shadow | tail -n 2
user2:$gost12512hash$vs18/gLTU.BNZfhz$Gby5XxXNbMz4Zhb6Rg7Uzf8tCykTWl0ynLCYsdJ.9CY0nurmkY
zl0SzizoOr.Ex07pdSO402vCQHnt.wGKFnF.:19564:0:99999:7:::
user3:$gost12512hash$3zJkoCuxXSfG.CaT$ZyRoq2N4Roagxeb9u83doUVEml0tkFwJUJk6qePyqGSW0ZpJLi
wdeDuD358j6lkTkfYChDdeF.9rKJEQevUcU1:19564:0:99999:7:::

Обязательно используйте sudoedit

Команда sudoedit – символическая ссылка на sudo -e. При вызове создает временную копию файла, которую может редактировать пользователь, вызывающий sudo. При этом сам редактор, в котором будет происходить работа с копией файла, запускается под обычным (непривилегированным) пользователем. При сохранении файла только в случае успешной проверки синтаксиса sudoedit заменит оригинальный файл его измененной версией.

Примечание

По умолчанию не позволяет редактировать файл, если родительская директория доступна для записи пользователем, вызывающим команду. Это предотвращает race condition, которая могла бы позволить пользователю перезаписать произвольный файл. Bug 707: разрешение пользователям редактировать файлы в директориях, к которым они имеют право на запись с помощью sudoedit, может позволить им обойти ограничения, установленные в конфигурации sudoedit (и фактически редактировать любой файл в системе).

Ограничивайте путь для исполняемых файлов

С помощью директивы secure_path определите пути, в которых будет выполняться поиск запускаемых через sudo утилит, когда не указан полный путь к файлу.

Defaults secure_path="/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin:/usr/local/sbin"

Используйте группы пользователей, оставляйте комментарии

Довольно простой рекомендацией является отказ от назначения прав на конкретных пользователей – используйте вместо этого группы. В этом случае и список правил будет короче, и за списками участников групп обычно удается лучше следить.

Давайте только минимально необходимые полномочия

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

Система аутентификации PAM

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

Система аутентификации PAM (англ. Pluggable Authentication Modules, «подключаемые модули аутентификации») – это набор разделяемых библиотек, которые позволяют интегрировать различные низкоуровневые методы аутентификации в виде единого высокоуровневого программного интерфейса. PAM реализует модульный подход к системе аутентификации, что позволяет системному администратору задавать правила аутентификации без необходимости перекомпиляции прикладных приложений.

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

В свою очередь приложениям и их разработчикам нет необходимости учитывать низкоуровневую логику, чтобы работать с бэкендами, например, базами данных, службой LDAP, файлами паролей, веб-службами с поддержкой WS-Security или другими бэкендами, некоторые из которых еще даже не существуют и будут созданы в будущем. Любой желающий (при наличии знаний и ресурсов) может создать свой собственный PAM-модуль, например, для работы приложений с новым сервисом аутентификации.

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

Состав и логическая схема PAM

На рисунке ниже представлена логическая схема взаимодействия компонентов PAM.

рис. 44 Логическая схема взаимодействия компонентов PAM

В качестве клиентов PAM могут выступать различные приложения, которым требуется выполнять аутентификацию. Это и программа login, которая запускается в самом конце процесса загрузки системы в текстовом режиме, это и рабочий стол fly-dm, который тоже проводит проверку аутентичности пользователей, это и такие приложения, как ssh, sudo, su и другие.

В состав PAM входят:

• Фреймворк PAM, который включает API (интерфейс прикладного программирования, служащий для взаимодействия с ним прикладных программ, которые используют эту систему) и SPI (интерфейс служебного программирования, служащий для взаимодействия фреймворка PAM с набором модулей).

• Конфигурация PAM – набор конфигурационных файлов, содержащих набор правил для проверки аутентификации пользователя (/etc/pam.conf и файлы из каталога /etc/pam.d/).

• Модули PAM – набор библиотек, определяющих логику проверки.

Модули PAM

Модули PAM – это подключаемые библиотеки. Они по умолчанию хранятся в каталогах /usr/lib/x86_64-linux-gnu/security/ и /lib/security/.

localadmin@astra:~$ ls /usr/lib/x86_64-linux-gnu/security/
pam_access.so     pam_gnome_keyring.so  pam_mail.so        pam_selinux.so     pam_tty_audit.so
pam_cracklib.so   pam_group.so          pam_mkhomedir.so   pam_sepermit.so    pam_umask.so
pam_debug.so      pam_issue.so          pam_motd.so        pam_shells.so      pam_unix.so
pam_deny.so       pam_keyinit.so        pam_namespace.so   pam_stress.so      pam_userdb.so
pam_echo.so       pam_kiosk2.so         pam_nologin.so     pam_succeed_if.so  pam_warn.so
pam_env.so        pam_lastlog.so        pam_permit.so      pam_systemd.so     pam_wheel.so
pam_exec.so       pam_limits.so         pam_pwhistory.so   pam_tally2.so      pam_xauth.so
pam_faildelay.so  pam_listfile.so       pam_rhosts.so      pam_tally.so
pam_filter.so     pam_localuser.so      pam_rootok.so      pam_time.so
pam_ftp.so        pam_loginuid.so       pam_securetty.so   pam_timestamp.so

localadmin@astra:~$ ls /lib/security/
pam_parsec_aud.so  pam_parsec_cap.so  pam_parsec_mac.so   pam_parsec_xauth.so

Модули бывают 4 типов:

• Auth (аутентификация) — модули этого блока проверяют подлинность пользователя. Они могут включать такие методы, как проверка пароля или использование двухфакторной аутентификации.

• Account (управление правами доступа) — этот блок выполняет проверки после успешной аутентификации, например, проверку срока действия учетной записи или групповых принадлежностей.

• Password (управление паролем) — модули этого блока обрабатывают такие операции с паролями, как их изменение или проверка сложности.

• Session (управление сеансом) — здесь определяются действия, выполняемые при открытии или закрытии сеанса. Например, установка переменных окружения или монтирование файловых систем.

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

Модули бывают стандартные и пользовательские:

• Стандартные модули, такие как pam_unix для локальной аутентификации. Эти официально поддерживаемые и широко используемые модули – проверенное и стабильно работающее решение.

• Сторонние разработчики могут создавать свои собственные модули, расширяя возможности аутентификации, что позволяет адаптировать систему PAM под конкретные потребности организаций.

Ниже перечислены несколько стандартных модулей с кратким описанием:

• pam_unix – обеспечивает аутентификацию через локальные учетные записи. Это основной модуль для проверки паролей в файле /etc/passwd.

• pam_tally2 – обеспечивает ограничение доступа после определенного числа неудачных попыток входа. Повышает безопасность, предотвращая подбор паролей методом перебора.

• pam_limits – предназначен для управления системными ресурсами для пользователей. Позволяет установить ограничения на использование ресурсов, таких как количество открытых файлов или объем памяти.

• pam_exec – обеспечивает выполнение внешних команд или сценариев в процессе аутентификации. Предоставляет возможность настраивать дополнительные действия при входе/выходе пользователя.

• pam_access – предназначен для управления доступом на основе IP-адресов. Позволяет определить, с каких IP-адресов разрешен или запрещен доступ.

Для работы компьютера в домене используется PAM-модуль от службы SSSD.

Конфигурационные файлы PAM

В PAM используется целый набор конфигурационных файлов в каталоге /etc/pam.d/. Файл /etc/pam.conf может содержать инструкции на тот случай, если PAM не обнаружит каталог /etc/pam.d. Однако в Astra Linux после установки никаких инструкций в этом файле нет, поэтому вы можете использовать только файлы из каталога /etc/pam.d/.

localadmin@astra:~$ ls /etc/pam.d/
chfn             common-session                 fly-dm-np  polkit-1    su-l
chpasswd         common-session-noninteractive  fly-wm     runuser     sumac.xauth
chsh             cron                           login      runuser-l   systemd-user
common-account   cups                           newusers   samba
common-auth      fly-dm                         other      su
common-password  fly-dm-greeter                 passwd     sudo

Имена этих файлов соответствуют именам идентификаторов, с которыми приложения запускают функцию pam_start. Обычно эти идентификаторы совпадают с именем приложения, например, у приложений login, fly-dm и др. Но отдельные приложения могут использовать несколько идентификаторов, например, утилита sudo использует sudo и sudo-i, а pam-модуль для сервера Apache может использовать уникальный идентификатор для каждого раздела веб-сайта.

Синтаксис конфигурационных файлов PAM

Посмотрим, например, содержимое файла /etc/pam.d/sudo:

localadmin@astra:~$ cat /etc/pam.d/sudo
#%PAM-1.0
@include common-auth
@include common-account
@include common-session-noninteractive
session required pam_limits.so

Как видите, с помощью директивы @include в него включены три других файла конфигурации: common-auth, common-account и common-session-noninteractive. И уже после них идет инструкция по использованию модуля pam_limits.so.

Посмотрим содержимое файла cat /etc/pam.d/common-auth:

#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.
# here are the per-package modules (the "Primary" block)
auth    [success=ignore default=2]      pam_localuser.so
auth    [success=1 default=ignore]      pam_succeed_if.so quiet user ingroup astra-admin
auth    [success=ignore default=die]    pam_tally.so per_user deny=8
auth    [success=1 default=ignore]      pam_unix.so nullok_secure try_first_pass
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

Каждая значащая строка должна содержать инструкцию для вызова модуля, которая может включать 3 обязательных элемента и один дополнительный:

• Тип модуля (обязательный) – существуют 4 типа модулей. О них было рассказано в предыдущем разделе.

• Флаги управления (обязательный) – определяет, как результат работы конкретного модуля (результат проверки, осуществляемой в нем) повлияет на процесс аутентификации в целом.

• Путь к модулю (обязательный) – это абсолютное или относительное имя пути к файлу PAM.

• Параметры модуля (дополнительный) – это список маркеров, которые могут быть использованы для влияния на функциональность модуля.

Флаги управления

Как мы видели на примерах в файле /etc/pam.d/common-auth, значение флагов может представлять собой одно слово, например, «required», или конструкцию из выражений в квадратных скобках, например, «[success=ignore default=2]».

В первом случае используется одно из 4 слов:

• required (обязательный) – указанный модуль PAM должен обязательно вернуть код успешной проверки, чтобы проверка этого сервиса считалось успешной. Но последующие модули будут вызываться дальше по цепочке, даже если результат проверки этого модуля был отрицательный и уже понятно, что проверка сервиса считается проваленной.

• requisite (необходимый) – указанный модуль PAM должен обязательно вернуть код успешной проверки, чтобы проверка этого сервиса считалась пройденной. В отличие от required, если результат проверки этого модуля был отрицательный и уже понятно, что проверка сервиса считается проваленной, последующие модули не будут вызываться, а сам сервис будет недоступен.

• sufficient (достаточный) – если указанный модуль PAM вернёт код успешной проверки, весь сервис будет разрешен, а остальные модули из файла вызываться не будут. Однако, если модуль PAM вернёт код проваленной проверки, оставшиеся модули пройдут проверку, а неудача данного модуля не будет приниматься во внимание.

• optional (дополнительный) – результат проверки указанного модуля PAM будет иметь значение, только если это единственный модуль для этого сервиса.

• include – флаг «include» позволяет включить другой файл конфигурации PAM в текущий файл. Это способ организации конфигурации для повторного использования.

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

[значение1=действие1 значение2=действие2 …]

Модули PAM могут возвращать около 30-ти значений, которые зависят от типа модуля (Auth, Account, Session или Password). Вот список возможных значений: success, open_err, symbol_err, service_err, system_err, buf_err, perm_denied, auth_err, cred_insufficient, authinfo_unavail, user_unknown, maxtries, new_authtok_reqd, acct_expired, session_err, cred_unavail, cred_expired, cred_err, no_module_data, conv_err, authtok_err, authtok_recover_err, authtok_lock_busy, authtok_disable_aging, try_again, ignore, abort, authtok_expired, module_unknown, bad_item, conv_again, incomplete и default. Значение default означает все значения, которые явно не заданы.

В качестве действия может быть указан один из следующих вариантов:

• ignore – игнорировать значение, результат не влияет на общий код возврата от этого модуля.

• bad – определяет значение как сбой модуля, но продолжит проверки других модулей.

• die – определяет значение как сбой модуля и провал проверки всего сервиса в целом.

• ok – определяет значение как успешную проверку модуля, но не отменяет сбой модуля.

• done – определяет значение как успешную проверку модуля и всего сервиса в целом.

• Цифра – определяет, сколько строк в конфигурации необходимо пропустить после текущей.

При этом надо учесть, что модуль возвращает только одно значение (из 30-ти возможных) и действие, назначенное именно этому значению, и будет выполнено.

Таким образом, вышеупомянутые 4 варианта значения флагов можно представить и в виде расширенной формы записи:

• required: [success=ok new_authtok_reqd=ok ignore=ignore default=bad]

• requisite: [success=ok new_authtok_reqd=ok ignore=ignore default=die]

• sufficient: [success=done new_authtok_reqd=done default=ignore]

• optional: [success=ok new_authtok_reqd=ok default=ignore]

Разберем подробнее расширенную запись, например, для required:

• success=ok – модуль вернул значение успешно. Проверка этого модуля будет считаться успешно пройденной. А проверка сервиса будет считаться успешно пройденной (на этом этапе), если ни один из предыдущих модулей не вызвал сбой.

• new_authtok_reqd=ok – модуль сигнализировал, что пароль пользователя желательно обновить. Проверка этого модуля будет считаться успешно пройденной. А проверка сервиса будет считаться успешно пройденной (на этом этапе), если ни один из предыдущих модулей не вызвал сбой.

• Ignore=ignore – модуль сообщает, что его проверку необходимо игнорировать. Результат проверки не будет учитываться при оценке сервиса в целом.

• default=bad – модуль предписывает считать все остальные значения как сбой. При их появлении проверка этого модуля (как и сервиса в целом) не будет пройдена, однако проверки других модулей продолжатся.

Параметры модуля

Рассмотрим параметры вызова модуля на примере конфигурационного файла cat /etc/pam.d/common-password:

#
# /etc/pam.d/common-password - password-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define the services to be
# used to change user passwords.  The default is pam_unix.
# Explanation of pam_unix options:
#
# The "sha512" option enables salted SHA512 passwords.  Without this option,
# the default is Unix crypt.  Prior releases used the option "md5".
#
# The "obscure" option replaces the old \`OBSCURE_CHECKS_ENAB' option in
# login.defs.
#
# See the pam_unix manpage for other options.
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.
# here are the per-package modules (the "Primary" block)
password        requisite                       pam_cracklib.so retry=3 minlen=8 difok=3
password        [success=1 default=ignore]      pam_unix.so obscure use_authtok try_first_pass gost12_512
# here's the fallback if no module succeeds
password        requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password        required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
password        optional        pam_gnome_keyring.so
# end of pam-auth-update config

Как вы можете видеть, при вызове модулей pam_cracklib.so и pam_unix.so используются параметры вызова модулей:

• pam_cracklib.so retry=3 minlen=8 difok=3

• pam_unix.so obscure use_authtok try_first_pass

Откроем приложение «Политика безопасности» (fly-admin-smc), Пуск ‣ Панель управления ‣ Безопасность ‣ Политика безопасности и перейдем в раздел Политики учетной записи -‣ Политика паролей.

рис. 45 Политика безопасности. Политика паролей.

Изменим значения:

• Минимальная длина пароля: 10 символов.

• Минимальное количество строчных букв: 2.

• Минимальное количество цифр: 3.

Вернемся в терминал и проверим содержимое конфигурационного файла /etc/pam.d/common-password еще раз:

cat /etc/pam.d/common-password | grep pam_

# used to change user passwords.  The default is pam_unix.
# Explanation of pam_unix options:
# See the pam_unix manpage for other options.
password        requisite                       pam_cracklib.so   retry=3 difok=3 minlen=10 lcredit=-2 ucredit=0 dcredit=-3 ocredit=0
password        [success=1 default=ignore]      pam_unix.so obscure use_authtok try_first_pass gost12_512
password        requisite                       pam_deny.so
password        required                        pam_permit.so
password        optional        pam_gnome_keyring.so

Как видим, значения параметров вызова модуля pam_cracklib изменились в соответствии со сделанными нами настройками:

• minlen=10 – минимальная длина пароля 10 символов.

• it=-2 – минимальное количество строчных букв 2.

• dcredit=-3 – минимальное количество цифр 3.

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

А теперь попробуйте установить службу sssd командой sudo apt install sssd, и вы убедитесь, что во всех общих файлах common-account, common-auth и др. появились строчки, подключающие модуль pam_sss.so от службы SSSD. Именно благодаря этому модулю и обеспечивается работа машины в домене.

Практика и тестирование

• Практическая работа: Модуль 10. Система аутентификации PAM и управление правами SUDO
• Тест: Модуль 10. Система аутентификации PAM и управление правами SUDO

Заключение

В этом модуле мы познакомились с механизмами повышения привилегий su/sudo, разобрались, как работают правила SUDO, и углубились в настройки PAM-стека.

Далее у нас будут основы автоматизации в Linux с применением сценариев Bash, чтобы почувствовать себя немного DevOps’ом.

Дополнительные источники информации:

• Официальный сайт sudo