1

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?

marhop
  • 111
  • 1
  • 3
  • sure, but why would you give the squid user access to the system's keytab (the system's shared secret to the directory)? – natxo asenjo Mar 06 '15 at 16:53
  • @natxoasenjo Because the system's keytab is created automatically anyway, whereas I would have to create the extra keytab for Squid manually. (Yeah, that's no big deal, but one step more to remember and document.) Or do you mean why the Squid user needs access to the keytab in the first place? Squid's Kerberos authentication helper needs read access to a keytab with the HTTP principal. – marhop Mar 06 '15 at 20:41
  • It's your system and your decision, but I would choose the least bit principle (http://blog.lastinfirstout.net/2008/04/system-management-by-least-bit.html) whereby squid has no business impersonating a computer account. It takes a little bit more of effort, yes. – natxo asenjo Mar 07 '15 at 16:17

1 Answers1

0

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 :-)

marhop
  • 111
  • 1
  • 3