Шестая часть от Dan Walsh: теперь про Kerberos и Credential Cache.

Перемещение KRB5 Credential Cache

Место расположения по умолчанию для Kerberos Credential Cache (CC) пользователя было изменено с /tmp на директорию пользователя в /run/user.

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

Владельцем кэша был пользователь, таким образом, допольнительные билеты, полученные пользователем, могли быть добавлены в кэш, так же как кэш мог быть им очищен или просто уничтожен.

Ради пользы пользователя, чьи данные были необходимы для предоставления доступа к удаленной домашней директории, программы входа не могли хранить данные авторизации в домашней директории пользователя. С тех пор, поскольку единственным местом, куда пользователь мог записывать, была директория /tmp, файл кэша хранился там по умолчанию.

Проблемы безопасности с Credential Cache в /tmp

Существует несколько проблем с хранением файла кэша в /tmp.

  1. Все пользователи системы могут записывать в /tmpfs. Для того, чтобы избежать возможности компрометации системы со стороны мошенника при записи данных авторизации пользователя в неправильное место, одни программы входа могли генерировать кэши с уникальными для пользователей именами. Другие использовали предсказуемые, но различные имена по другим причинам.
  2. Но в случае, если имя кэша пользователя нельзя было предсказать, это могло стать проблемой для служб, которые не запускаются как часть сессии пользователя, и которые, по этой причине, не могут обратиться к переменной окружения $KRB5CCNAME для поиска используещегося кэша. Такие службы, например, rpc.gssd (демон, который управляет клиентской частью “керберизованного” NFS) исторически были созданы для облегчения поиска того, какое имя имеет файл kerberos credential cache, и они делали это, прочесывая директорию /tmp в поисках наиболее подходящего соответствия.
  3. /tmp могла быть настроена используя pam_namespace, таким образом, процессы, запущенные в пространстве пользователя ‘root’ видели другую директорию /tmp, чем пользователи видели при входе в систему. Это мешало службам даже иметь возможность поиска Credential Cache.
  4. Директория /tmp часто не является временной файловой системой. Выход из системы или перезагрузка системы не могли гарантировать, что Credential Cache будет удален/уничтожен.

SSSD приходит на помощь в Fedora 18

В Fedora 18 файл Credential Cache был перемещен SSSD, System Security Services Daemon, в /run/user/UID/krb5cc_XXXXXX/tkt. Где XXXXXX - случайное число.

Например, на моей машине, при выполнении klist я вижу следующее:

> klist
Ticket cache: DIR::/run/user/3267/krb5cc_ca3a4331e17e8e80cb0c46ea507840bc/tkt
Default principal: dwalsh@REDHAT.COM

Valid starting     Expires            Service principal
10/12/12 12:48:17  10/12/12 22:48:17  krbtgt/REDHAT.COM@REDHAT.COM
    renew until 10/12/12 12:48:17

Заметка: Наличие двух двоеточий между “DIR” и путем имени ccache указывает, что источник именованного пути - директория, использующаяся для хранения файла кэша (или, возможно, более чем одного файла кэша).

Основное преимущество в том, что run/user/3267 и ее поддиректории имеют маску 700, а их владельцем является dwalsh:dwalsh. Другим пользователям неизвестно, что кэш находится здесь, и они не знают, насколько он велик или когда в последний раз к нему был доступ. Это означает, что мы можем не обращать внимания на то, что другие пользователи могут попытаться навести бардак в /tmp.

Во-вторых, /run - всегда tmpfs, поэтому если пользователь выйдет из системы, кэш будет уничтожен, или если система рухнет, файл кэша уйдет вместе с ней.

Так как билеты хранятся в предсказуемом месте, привилегированные процессы, вроде rpc.gssd, могут легко найти корректные билеты. А так как билеты находятся за пределами /tmp, pam_namespace теперь не скрывает credential cache от системных служб.

В итоге, SSSD сейчас может фактически получить множество билетов из разных доменов и просто хранить их в директории /run, позволяя пользователю логиниться во множество доменов Kerberos в одно и то же время.