[Dovecot] Automatically Cleaning Kerberos Credential Cache Files

[Ben Morrow]

At  7PM -0500 on 10/12/12 you (Maura Dailey) wrote:
> On 12/10/2012 05:31 PM, Ben Morrow wrote:
> > At  3PM -0500 on 10/12/12 you (Maura Dailey) wrote:
> >> I'm in a situation here at work where I'm trying to support a mixed
> >> network of OS X and RHEL desktop machines with a Postfix/Dovecot
> >> combination.
> >>     - user account information is stored in LDAP
> >>     - user credentials are in MIT Kerberos
> >>     - server is running RHEL 6/Dovecot 2.0.9/Postfix 2.6.6
> >>
> >> I am currently using the PAM passdb module to authenticate my users (I
> >> began to have trouble with using GSSAPI directly). After I implemented
> >> it, a few weeks later, I noticed that some users were no longer getting
> >> their mail if they hadn't logged in during the past day. Postfix's mailq
> >> showed that hundreds of messages were backing up in the queue. I
> >> eventually tracked it down to leftover Kerberos credential cache files
> >> (/tmp/krb5cc_????) sitting in /tmp on the mail server. The presence of
> >> expired credential files was preventing Postfix from delivering mail to
> >> those users' mail spools. If I delete the credential files manually,
> >> Postfix immediately delivers the queued emails.
> > This is rather odd. Is krb5-authenticated NFS involved here, or does
> > Postfix's delivery make any other use of Kerberos? The only other thing
> > I can think of is that so many expired ccaches are accumulating that the
> > user goes over their inode quota.
> 
> Each user has one credential cache file in /tmp on the mail server after 
> logging into Dovecot. We aren't using randomized names, so everything is 
> in the standard format /tmp/krb5cc_uid. We do use KRB5 authenticated 
> (and encrypted) NFS, but we don't deliver mail to home directories. 
> Since all users are "real" users, and our office size is small, everyone 
> has a mail spool directory on the mail server.

Hmm. I don't have much experience with KrbNFS, and none at all on Linux,
but the implementations I've seen seem to be terribly flaky about
passing krb5 creds to the kernel. (What they ought to do is implement
AFS' aklog and setpag; they're irritating, but at least they're
well-understood...)

In any case, it's likely that the delivery process looks in the user's
home directory even if delivery is to a separate mail spool, unless
you've taken steps to prevent this. For instance, Postfix's local(8)
checks for ~/.forward by default, LDAs like procmail or maildrop look
for similar per-user RC files, and Dovecot's LDA looks for (at least)
~/.dovecot.sieve. Is it possible that the NFS code returns a different
error for 'no ccache present' vs 'ccache present but the creds have
expired', such that Postfix will carry on delvering if it gets the first
error but not the second?

<snip>
> > Well, I don't use RH (I use FreeBSD), but I use and would recommend Russ
> > Allbery's pam_krb5.so, which may or may not be the same as the normal
> > pam_krb5.so provided by your system. It has options to control whether
> > and where ccaches are created; assuming Dovecot doesn't need krb5 creds
> > (say, for NFS), you would probably be better off telling it not to
> > create a permanent ccache at all.
> >
> > http://www.eyrie.org/~eagle/software/pam-krb5/
> I haven't had to configure pam_krb5.so directly before (we use the Red 
> Hat/Fedora configured default, pam_sss.so, which claims to be a one stop 
> shop for LDAP/Kerberos/NIS,etc.), but it does seem to have more options. 
> We certainly don't need credential caches to stick around for email 
> users. All the mail spools are stored on locally mounted storage on the 
> mail server.

Where do users' private IMAP folders live? Are they in the mail spool as
well, or are they in the user's home directory? Once a user has logged
in Dovecot will change directory to their home directory (as returned by
the userdb), so you may find you *do* need ccaches if they are on KrbNFS.

> > This certainly does all sound related. What are the ccache files called:
> > are they just /tmp/krb5cc_UID or is there a random portion as well? Are
> > they being created with the correct permissions, and are there any
> > security policies (SELinux or ACLs of some kind) set up which might
> > interfere with their creation or destruction?
> No random portion (the only application we have configured with random 
> ccache names is SSH), just the usual /tmp/krb5cc_uid.

(I assume you're aware of the potential DoS here, given that /tmp is
world-writable and sticky? I'm not sure if there's anything you can do
about it if you're using KrbNFS, though.)

> Permissions appear 
> correct, they belong to the appropriate user and group accounts. The 
> SELinux permissions are set to: system_u:object_r:user_tmp_t:s0. This is 
> different from the machine's credential cache 
> (system_u:object_r:gssd_tmp_t:s0), but I've disabled and re-enabled 
> SELinux during different parts of my testing and didn't notice any errors.

I know nothing whatever about SELinux, but this might be relevant. gssd
handles client-side credentials for NFS, so if it ends up unable to
snoop on a user's ccache you will have problems. (This is why you can't
rename them to something secure, and is the problem aklog solves.)

> Using GSSAPI directly doesn't create any cached credential files on the 
> server. However, I just verified that I'm still sporadically getting the 
> duplicate tickets (two lines for imap/hostname.server.com at SERVER.COM, 
> with identical expiration dates).

That's odd, but it shouldn't be a problem. A valid ticket is a valid
ticket, regardless of whatever other tickets might exist.

> It comes and goes. I have a few users 
> testing it for me, and they'll let me know if their logins break 
> tomorrow like they have in the past once the normal log in period 
> elapses. Since the "fix" for that problem is to log into the mail 
> server, I have a hard time testing for the problem myself (being logged 
> into the mail server nearly continuously just now).

It sounds to me as though clearing out dead ccaches, maybe even with an
hourly-or-more cronjob that only deletes them if they've expired, will
fix the problem for the moment. A more fundamental fix will require
understanding when your PAM modules delete ccaches, and possibly turning
off Postfix features like ~/.forward if you're not using them.

AFAICS the only piece of Dovecot configuration that might be relevant at
this point is that a user's Dovecot home directory does not have to be
the same as their 'real' home directory, so you can (if necessary) move
all Dovecot-related files onto a local disk. See
http://wiki2.dovecot.org/AuthDatabase/Passwd .

Ben