On Wed, 2005-10-19 at 15:45 +0200, Jelmer Vernooij wrote:
Want to discuss ideas?
I have been considering:
- start up two pipe connected processes, a network filter and libexec/dovecot/imap, the filter does the gss_wrap, gss_unwrap etc
- create a io library filter layer This sounds like the sanest way of handling this to me. You'd have to export the GSS security context from the login process to the user process somehow, but that shouldn't be a problem with gss_{ex,im}port_sec_context().
If I understand this correctly, the whole thing begins from dovecot-auth process. From there on the security context is exported to login process as an authentication reply. Is it small enough that the 8192 byte input buffer is always enough?
Since at that point user has logged in, there's no need for login process to actually do anything else with the security context than get it passed onto imap process. Or this could be done by dovecot-auth -> master -> imap route using USER reply. Maybe better that way. In any case login/master processes wouldn't have to know anything about GSSAPI there, they'd just forward parameters from dovecot-auth blindly (I think master already does?).
Or it could be done in login process as a proxy the same way as SSL is currently handled. Login process is a bit hacky anyway so having GSSAPI proxy there wouldn't make it much worse :) Also the plus side there is that if there happens to be any exploitable security holes in GSSAPI library, login process would be running in chroot and attacker wouldn't get direct access to anyone's mails.
Doing it in imap/pop3 process would allow it to be done using a plugin though.. The "plugin" could be statically linked, but it could still be fully isolated from the imap/pop3 code itself. configure script could just generate some imap-plugins.c which contains gssapi_plugin_init() call or something after which it does all the rest internally. Possibly requires some more hooks to be added to main code.