Kerberos keytab permissions

kerberossquid

Can you share some thoughts on whether a Kerberos keytab should be readable only by root – under all circumstances? Or are there exceptions to this rule?

I am setting up a Squid proxy on Debian Jessie for Kerberos authentication with Active Directory. Most documentation advises to create a keytab for Squid containing an entry for the "HTTP" Service Principal.

However, if I join my system to an Active Directory domain, e.g., with realmd, this will already create a keytab, namely /etc/krb5.keytab. I can even make sure this keytab contains the necessary entry for the "HTTP" Service Principal:

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

So instead of creating a second keytab for Squid I could simply give read permissions for /etc/krb5.keytab to the process running Squid (which is the user proxy on Debian).

I am aware that it is considered a security issue if any user but root has access to the system keytab /etc/krb5.keytab. However, if my server hosts no services but the Squid proxy a keytab specifically created for Squid (e.g., with net ads keytab create && net ads keytab add HTTP) would contain more or less the same information as the system keytab anyway. (Or wouldn't it?)

So will I leap into any security holes when setting it up this way?

Best Answer

I think I should rephrase my question, thereby answering it: How do I create a keytab that contains only entries for the HTTP SPN?

If I create a new keytab for Squid with the following commands as it is described in the Squid wiki

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

then the new keytab /etc/squid3/HTTP.keytab will contain entries for the same SPNs as the system keytab plus entries for the 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

This is why I did not see the point in denying Squid read permissions for the system keytab /etc/krb5.keytab - it had the same SPNs in its own keytab anyway.

However, if I make HTTP.keytab contain only HTTP entries the different permissions will make sense: Then Squid can only use the HTTP SPNs it actually needs - but no other SPNs that may be contained in the system keytab. That can be done as follows:

# net ads keytab add HTTP

This adds the HTTP SPN to the system keytab. Then we create a new keytab based on the system keytab and in this new keytab delete all but the HTTP SPNs:

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

Repeat the last step until only entries are left that start with http or HTTP. Then write the result to a new file and set the permissions:

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

The resulting keytab now contains only HTTP SPNs:

# 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

Works for me :-)

Related Topic