Не могли бы вы поделиться некоторыми мыслями о том, должна ли таблица ключей Kerberos быть доступна для чтения только root? при любых обстоятельствах? Или есть исключения из этого правила?
Я настраиваю прокси-сервер Squid на Debian Jessie для аутентификации Kerberos с помощью Active Directory. Наиболее документация советует создать keytab для Squid, содержащий запись для субъекта-службы "HTTP".
Однако, если я присоединяю свою систему к домену Active Directory, например, с область, это уже создаст keytab, а именно /etc/krb5.keytab. Я даже могу убедиться, что эта вкладка содержит необходимую запись для субъекта-службы HTTP:
# adcli preset-computer -D mydomain.org --service-name HOST --service-name HTTP proxy.mydomain.org
# realm join mydomain.org
Поэтому вместо создания второй вкладки для Squid я мог бы просто дать разрешения на чтение для /etc/krb5.keytab процессу, на котором запущен Squid (который является прокси-сервером пользователя в Debian).
Я знаю, что это считается проблемой безопасности, если любой пользователь, кроме root, имеет доступ к системной клавише /etc/krb5.keytab. Однако, если на моем сервере нет служб, кроме прокси-сервера Squid, вкладка клавиш, специально созданная для Squid (например, с net ads keytab create && net ads keytab add HTTP) в любом случае будет содержать более или менее ту же информацию, что и системная клавиша. (Или нет?)
Итак, я наткнусь на какие-нибудь дыры в безопасности при такой настройке?
Думаю, мне следует перефразировать свой вопрос, тем самым отвечая на него: как мне создать ключевую вкладку, содержащую только записи для HTTP SPN?
Если я создам новую вкладку для Squid с помощью следующих команд, как описано в Кальмар вики
# export KRB5_KTNAME=FILE:/etc/squid/HTTP.keytab
# net ads keytab CREATE
# net ads keytab ADD HTTP
# unset KRB5_KTNAME
затем новый keytab /etc/squid3/HTTP.keytab будет содержать записи для тех же SPN, что и системная клавиша плюс записи для HTTP SPN:
# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- -----------------------------------------
2 PROXY$@mydomain.org
2 host/proxy.mydomain.org@mydomain.org
2 host/proxy@mydomain.org
# klist -k /etc/squid3/HTTP.keytab
Keytab name: FILE:/etc/squid3/HTTP.keytab
KVNO Principal
---- -----------------------------------------
2 PROXY$@mydomain.org
2 host/proxy.mydomain.org@mydomain.org
2 host/proxy@mydomain.org
2 http/proxy.mydomain.org@mydomain.org
2 http/proxy@mydomain.org
2 HTTP/proxy.mydomain.org@mydomain.org
2 HTTP/proxy@mydomain.org
Вот почему я не видел смысла отказывать Squid в разрешении на чтение для системной вкладки /etc/krb5.keytab - в любом случае у него были те же имена SPN на собственной клавиатуре.
Однако если я сделаю HTTP.keytab содержать только HTTP-записи с разными разрешениями будут иметь смысл: тогда Squid сможет использовать только те HTTP-имена SPN, которые ему действительно нужны, но никакие другие SPN, которые могут содержаться в системной ключевой вкладке. Это можно сделать следующим образом:
# net ads keytab add HTTP
Это добавляет HTTP SPN к системной клавише. Затем мы создаем новую keytab на основе системной keytab и в этой новой keytab удаляем все, кроме HTTP SPN:
# ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: list
ktutil: delent <number of non-HTTP entry>
Повторяйте последний шаг, пока не останутся только записи, начинающиеся с http или HTTP. Затем запишите результат в новый файл и установите разрешения:
ktutil: wkt /etc/squid3/HTTP.keytab
ktutil: quit
# chown root:proxy /etc/squid3/HTTP.keytab
# chmod 640 /etc/squid3/HTTP.keytab
Получившаяся в результате keytab теперь содержит только HTTP SPN:
# klist -k /etc/squid3/HTTP.keytab
Keytab name: FILE:/etc/squid3/HTTP.keytab
KVNO Principal
---- -----------------------------------------
2 http/proxy.mydomain.org@mydomain.org
2 http/proxy@mydomain.org
2 HTTP/proxy.mydomain.org@mydomain.org
2 HTTP/proxy@mydomain.org
Работает для меня :-)