tcb - альтернативная схема управления теневыми паролями
Задача
Согласно традиционной схеме управления теневыми паролями, хеши паролей
всех пользователей, а также информация о сроке их действия хранится в
едином файле -
/etc/shadow.
Таким образом, процесс, которому предоставляется доступ к информации о
пароле одного из пользователей системы, автоматически получает права,
достаточные для получения аналогичного доступа к информации о паролях
всех остальных пользователей. Этот явный изъян в дизайне легко проследить
на примере утилиты
passwd(1).
Предположим, что политика безопасности позволяет непривилегированным
пользователям изменять собственные пароли. Какими бы ни были права
доступа к файлу
/etc/shadow,
программа
passwd(1),
запущенная непривилегированным пользователям U, должна иметь возможность
вносить изменения в этот файл. Если злоумышленник U найдёт способ взять
под свой контроль процесс
passwd(1)
(с помощью ошибки непосредственно в коде программы
passwd(1),
используемых ею библиотеках, или в ядре), то этот пользователь получит
возможность менять пароли всех пользователей и таким образом возьмёт
под свой контроль операционную систему.
Решение
Решение проблемы простое - каждому пользователю соответствует отдельный
теневой shadow-файл. Поскольку теневой файл пользователя U принадлежит
этому пользователю U, то программа
passwd(1),
запущенная U, уже не требует рутовых прав.
Все теневые файлы пользователей располагаются в каталоге
/etc/tcb:
drwx--x--- 2 root shadow 1024 Май 4 01:18 /etc/tcb
Для каждого пользователя создаётся подкаталог в
/etc/tcb
с соответствующими правами доступа:
# ls -l /etc/tcb
всего 2
drwx--s--- 2 root auth 1024 Май 4 01:18 root
drwx--s--- 2 user auth 1024 Май 4 01:18 user
и т.д.
Каждый такой подкаталог содержит теневой файл, содержащий информацию о
пароле соответствующего пользователя:
# ls -l /etc/tcb/user
всего 1
-rw-r----- 1 user auth 91 Май 4 01:18 shadow
Эти персональные каталоги используются для хранения временных файлов и
блокировочных файлов, создаваемых во время смены пароля либо изменения
другой информации, хранящейся в теневом файле.
Преимущества
Описанный выше дизайн обладает следующими преимуществами:
1.
Утилита
passwd(1)
должна быть установлена с правами SGID-shadow, а не SUID-root.
Утилита
chage(1)
и вспомогательная программа
/usr/lib/chkpwd/tcb_chkpwd
также должны быть установлены с правами SGID-shadow; это значит, что в
соответствии со схемой
tcb
запущенные процессы будут обладать правами, достаточными для изменения
только пользовательской теневой записи. Таким образом, весь вред,
который может причинить злоумышленник в случае обнаружения ошибки
в реализации этих программ, ограничен возможностью изменения своего
собственного теневого файла.
2.
Если процессу необходим доступ по чтению ко всем теневым файлам сразу,
достаточно дополнительно включить его в группы "shadow" и "auth".
3.
Схема
tcb
полностью прозрачна для приложений, которым требуется читать информацию о
паролях. Разделяемая библиотека libnss_tcb реализует интерфейс к функции
getspnam(3)
и другим функциям работы с теневыми записями. Смена паролей
обеспечивается PAM-модулем
pam_tcb(8).
Информацию о введении в действие схемы
tcb
можно прочесть в
tcb_convert(8),
где рассказано, как это сделать наиболее безболезненно.
Недостатки
Честно говоря, их всего несколько, и они крайне незначительные:
1.
Невозможно установить блокировку всей теневой базы данных (см.
tcb_unconvert(8)).
2.
Процесс, обладающий доступом по чтению ко всем теневым файлам, как
это описано выше, автоматически обладает доступом по изменению своего
собственного теневого файла.
3.
Невозможно предоставить процессу права доступа только по чтению к одному
конкретному теневому файлу иначе как исполняя этот процесс с правами
соответствующего пользователя.
4.
Средства управления доступом пользователей требуют значительной доработки
для обеспечения поддержки схемы tcb.
Некоторые файловые системы ограничивают возможное число жёстких ссылок
для файлов. Например, в файловой системе ext2 никакой файл не может
содержать более 32000 жёстких ссылок. Это значит, что каталог
/etc/tcb,
размещённый на такой файловой системе, может содержать не более 31998
подкаталогов. При использовании схемы размещения файлов, описанной выше,
это ограничение файловой системы автоматически приводит к ограничению
максимального числа пользователей тем же числом 31988.
Решение: каталог с теневым файлом для пользователя U может быть помещён
не только в каталог
/etc/tcb,
но и в каталог
/etc/tcb/:some/path.
В случае использования второго варианта должна быть создана символическая
ссылка
/etc/tcb/U -> /etc/tcb/:some/path/U.
В реализации tcb, начиная с версии 0.9.8, каталоги с именами,
удовлетворяющими шаблону
/etc/tcb/:*,
не рассматриваются как каталоги с теневыми файлами. Эти имена
зарезервированы для символических ссылок на каталоги с теневыми файлами.
По умолчанию, средства управления доступом пользователей, работающие
непосредственно с каталогами, содержащими теневые файлы, создают эти
каталоги непосредственно в
/etc/tcb;
в ситуации, когда число пользователей в
tcb
может превысить ограничение файловой системы, администратор системы
может перейти на второй вариант размещения каталогов с теневыми файлами,
изменив параметр
TCB_SYMLINKS
в конфигурационном файле
login.defs(5).
Историческая справка
Первая публичная версия реализации альтернативной схемы управления
теневыми паролями
tcb
появилась 12 ноября 2001 года в ОС Openwall GNU/*/Linux.
Дата появления
tcb
в ALT Linux Sisyphus - 20 декабря 2001 года.
аудит кода, адаптация схемы
tcb
для ОС ALT Linux, перевод документации по
tcb
на русский язык.
Реализация PAM-модуля
pam_tcb
призвана обеспечивать обратную совместимость с
pam_unix,
ввиду чего некоторые решения были заимствованы из
pam_unix.
Некоторые менее критичные фрагменты кода, а также в некоторой мере
композиция кода взяты из реализации модуля
pam_unix
в Linux-PAM.
Имена соавторов
pam_unix
приведены в каталоге orig_copyright/ исходного кода схемы
tcb.
