separate keytab for pam_krb5

[Russ Allbery]

Stefan Skoglund <Stefan.Skoglund at agj.net> writes:

> I had a bit of problems unlocking the X session and after reading
> other people description of the same symptom i did find the trigger for
> it in my /etc/krb5.conf:
> ---
> verify_ap_req_nofail = true
> ---

> I dropped it and things started to 'work' again.

Hm, normally you shouldn't need to do this since the libraries will
automatically default to nofail if the keytab is unreadable by the user
verifying initial tickets.

> This is of course unsatisfactory and so i now wonder:
> pam_krb5 can use an separate keytab when authenticating and if i
> understands it properly that keytab should contain the 'host/...'
> principal for the local host and the keytab needs to be readable by all
> authenticated local users.

> What is the security implications of this ?

It can use a separate keytab (well, mine can at least; I'm not sure about
Red Hat's), but there isn't any real point, since indeed it would have to
be readable by all local users, which means that all local users have all
the information required to spoof KDC replies.  Given that preventing
spoofing of KDC replies is the whole point of this step in the first
place, you have gained almost nothing over just turning off this
verification for xlock.  (Well, I suppose you defend against an attacker
who was never able to get access to the local system, but nontheless is
attacking your screen lock program, but I was never able to convince
myself that this is a significant portion of the problem.)

The right solution to the problem is to have a local oracle that the PAM
module can authenticate to and which will tell the PAM module whether the
credentials are valid.  That oracle can then run in a separate security
context as root and have access to the keytab.  I plan on adding such
functionality to my PAM module once I find some time, but I haven't gotten
a chance to work on it yet.  (I want to have a daemon that listens on a
UNIX domain socket.  It would be somewhat simpler to provide a setuid
helper program, but I think that's a much higher security risk.)

It's possible that the work on GSS-API extensions for obtaining initial
credentials and on providing a GSS-API proxy for all system processes that
need to do KDC interactions will get far enough along before I get to this
that I could just use that instead.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>