If a Kerberos keytab has multiple entries, how keep wrong person from using an entry?

0
votes

Kerberos keytab files are located at /etc/krb5/krb5.keytab by convention, which is a non-user-specific location. That keytab (and all keytabs) can contain multiple entries.

Let's suppose a computer has three users: Alice, Bob, and Eve. They each add an entry to the shared keytab through the following process, but with their respective names:

$ ktutil
ktutil:  addent -password -p [email protected] -e aes256-cts -k 1
Password for [email protected]:
ktutil:  list -e
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    1            [email protected] (aes256-cts-hmac-sha1-96)
ktutil:  wkt krb5.keytab

Later on, Alice, Bob, and Eve can all use their keytab entry to authenticate a script like so, respectively:

> kinit [email protected] -k -t mykeytab; myscript

What keeps Eve from using Alice or Bob's entries in the keytab? I haven't found anything explicitly covering how to keep keytabs with multiple entries secure. If we don't want Eve using Alice's entry, should they have separate keytabs protected by file permissions?

Or, is this the Kerberos trust model? If they each have access to this keytab, then we implicitly trust them to use any entry? Should we only have trusted services sharing a keytab?

Thanks in advance for tips. Just want to make sure I'm understanding the trust model correctly.

1
securitykerberosspnegokeytab
Keytabs are usually created for the service users/accounts. Application can use the keytab to get the ticket for itself or on some user's behalf if the service account is allowed to delegate or impersonate. They are stored on secure location with access to very specific services/users. Sharing keytab among different users is very odd case and doesn't look practical. - Bhushan Karmarkar
"Kerberos keytab files are located at /etc/krb5/krb5.keytab by convention" >> ambiguous; what does that mean?? that you have one single keytab file for all users?? and who was crazy enough to set up that "convention"??? - Samson Scharfrichter
/etc/krb5.keytab (on RedHat) is the default location for authentication services (e.g. SSSD) to get their pwd and authenticate against a Kerberos KDC, and manage the security of the whole Linux system. Only root should have access. - Samson Scharfrichter
Ah, that makes sense and helps a lot, thank you. Also, yes, it would have been better if I'd cited my source regarding the location of the krb5.keytab. The truth is, I'd been researching a lot that day and I wasn't certain anymore, I just knew I'd seen it in at least two places. - Becca Petrin

1 Answers

3
votes

A keytab file contains the password for one (or more) Kerberos principal(s), pre-encrypted with one (or more) cypher(s). Actually it's a history of passwords, new passwords being added "on top" of older passwords.

Keytab files must be secured just as any other password file i.e. with strict FS access privileges.

Using one single keytab file as a dump for multiple principals makes no sense - unless all these principals are used by various services or jobs that run under the same Linux account. And even then it's probably a bad idea.
For instance, read about how Ambari manages keytabs for the various Hadoop services (incl. the "spnego" keytab shared by all services with an HTTP interface), and focus on the chown and chmod commands:
https://ambari.apache.org/1.2.5/installing-hadoop-using-ambari/content/ambari-kerb-1-4.html