Permissões de keytab do Kerberos

Question

Você pode compartilhar algumas idéias sobre se um keytab do Kerberos deve ser legível somente pelo usuário root - em todas as circunstâncias ? Ou existem exceções a essa regra?

Estou configurando um proxy Squid no Debian Jessie para autenticação Kerberos com o Active Directory. A maior parte da documentação aconselha a criar um keytab para o Squid contendo uma entrada para o Principal do Serviço "HTTP".

No entanto, se eu unir meu sistema a um domínio do Active Directory, por exemplo, com realmd , isso já criará um keytab, ou seja, /etc/krb5.keytab . Eu posso até mesmo ter certeza de que este keytab contém a entrada necessária para o "HTTP" Service Principal:

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

Então, ao invés de criar um segundo keytab para o Squid, eu poderia simplesmente dar permissões de leitura para /etc/krb5.keytab para o processo que executa o Squid (que é o proxy do usuário no Debian).

Estou ciente de que é considerado um problema de segurança se qualquer usuário, exceto o root, tiver acesso ao sistema keytab /etc/krb5.keytab . No entanto, se o meu servidor não hospedar serviços, mas o proxy Squid, um keytab criado especificamente para o Squid (por exemplo, com net ads keytab create && net ads keytab add HTTP ) conterá mais ou menos a mesma informação que o keytab do sistema. (Ou não?)

Então, vou entrar em qualquer falha de segurança ao configurá-lo desta maneira?

    

Answer 1

Eu acho que eu deveria reformular minha pergunta, respondendo assim: Como eu crio um keytab que contenha apenas entradas para o HTTP SPN?

Se eu criar um novo keytab para o Squid com os seguintes comandos, conforme descrito no wiki do Squid

# export KRB5_KTNAME=FILE:/etc/squid/HTTP.keytab
# net ads keytab CREATE
# net ads keytab ADD HTTP
# unset KRB5_KTNAME

então o novo keytab /etc/squid3/HTTP.keytab conterá entradas para os mesmos SPNs que as entradas keytab plus para o HTTP SPN:

# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- -----------------------------------------
   2 [email protected]
   2 host/[email protected]
   2 host/[email protected]

# klist -k /etc/squid3/HTTP.keytab
Keytab name: FILE:/etc/squid3/HTTP.keytab
KVNO Principal
---- -----------------------------------------
   2 [email protected]
   2 host/[email protected]
   2 host/[email protected]
   2 http/[email protected]
   2 http/[email protected]
   2 HTTP/[email protected]
   2 HTTP/[email protected]

É por isso que eu não entendi o ponto de negar permissões de leitura do Squid para o sistema keytab /etc/krb5.keytab - ele tinha os mesmos SPNs em seu próprio keytab de qualquer maneira.

No entanto, se eu fizer HTTP.keytab conter somente entradas HTTP, as diferentes permissões farão sentido: Então o Squid só pode usar os SPNs HTTP de que realmente precisa - mas nenhum outro SPN que possa estar contido o keytab do sistema. Isso pode ser feito da seguinte forma:

# net ads keytab add HTTP

Isso adiciona o HTTP SPN ao keytab do sistema. Em seguida, criamos um novo keytab com base no keytab do sistema e, neste novo keytab, excluímos todos, exceto os SPNs HTTP:

# ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: list
ktutil: delent <number of non-HTTP entry>

Repita a última etapa até restarem apenas as entradas que começam com http ou HTTP . Em seguida, escreva o resultado em um novo arquivo e defina as permissões:

ktutil: wkt /etc/squid3/HTTP.keytab
ktutil: quit
# chown root:proxy /etc/squid3/HTTP.keytab
# chmod 640 /etc/squid3/HTTP.keytab

O keytab resultante agora contém apenas HTTP SPNs:

# klist -k /etc/squid3/HTTP.keytab
Keytab name: FILE:/etc/squid3/HTTP.keytab
KVNO Principal
---- -----------------------------------------
   2 http/[email protected]
   2 http/[email protected]
   2 HTTP/[email protected]
   2 HTTP/[email protected]

Funciona para mim: -)