Вопросы Теги

Kerberos keytab полномочия

Можно ли совместно использовать некоторые мысли о том, должен ли Kerberos keytab быть читаемым только корнем - при всех обстоятельствах? Или есть ли исключения к этому правилу?

Я настраиваю прокси Сквида на Debian Jessie для аутентификации Kerberos с Active Directory. Большая часть документации советует для создания keytab для Сквида, содержащего запись для Сервисного Принципала "HTTP".

Однако, если я соединю свою систему с доменом Active Directory, например, с realmd, то это уже создаст keytab, а именно, /etc/krb5.keytab. Я могу даже удостовериться, что этот keytab содержит необходимую запись для Сервисного Принципала "HTTP":

# adcli preset-computer -D mydomain.org --service-name HOST --service-name HTTP proxy.mydomain.org
# realm join mydomain.org

Таким образом вместо того, чтобы создать второй keytab для Сквида я мог просто дать полномочия чтения для /etc/krb5.keytab к Сквиду выполнения процесса (который является пользовательским прокси на Debian).

Я знаю, что считается проблемой безопасности, если любой пользователь, но корень имеет доступ к системе keytab /etc/krb5.keytab. Однако, если мой сервер не размещает сервисов, но Сквид проксируют keytab, конкретно созданный для Сквида (например, с net ads keytab create && net ads keytab add HTTP) содержал бы более или менее ту же информацию как система keytab так или иначе. (Или не был бы он?)

Таким образом, я прыгну в какие-либо дыры в системе безопасности при установке его этот путь?

1
задан 6 March 2015 в 18:39
1 ответ

Думаю, мне следует перефразировать вопрос, тем самым отвечая на него: Как мне создать keytab, который содержит только записи для HTTP SPN?

Если я создам новую keytab для Squid с помощью следующих команд, как это описано в Squid wiki 

# 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, что и системная keytab , плюс записи для 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 в разрешении на чтение для системного keytab /etc/krb5.keytab - у него все равно были те же SPN в его собственном keytab.

Однако, если я make HTTP.keytab содержать только записи HTTP, разные разрешения будут иметь смысл: тогда Squid сможет использовать только те HTTP SPN, которые ему действительно нужны - но не другие r 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

Результирующая таблица ключей теперь содержит только 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

Подходит для меня: -)

0
ответ дан 4 December 2019 в 08:00

Теги

Похожие вопросы