[Dovecot] [PATCH] Support for GSSAPI SASL Mechanism
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Attached is a patch against current CVS that adds support for the
GSSAPI SASL mechanism. It was written from scratch, after reading the
patch from Colin Walters against a much older version of dovecot.
Other then support for the 'GSSAPI' mechanism, it contains the
following changes:
- - Added 'auth_krb5_keytab' option for overriding default keytab
location. The gssapi library already uses the environment variable
KRB5_KTNAME to allow overriding of the keytab location, so I didn't
have to make any changes on the login process side.
- - Added 'need_passdb' member to mech_module and allow having no
passdb's specified if no mechanisms need them (only useful for GSSAPI
at the moment)
Cheers,
Jelmer
- --
Jelmer Vernooij
"JV" == Jelmer Vernooij jelmer@samba.org writes:
JV> Attached is a patch against current CVS that adds support for the
JV> GSSAPI SASL mechanism. It was written from scratch, after reading
JV> the patch from Colin Walters against a much older version of
JV> dovecot.I too have been working on getting a working GSSAPI patch against current CVS and have taken a similar approach.
Any idea if this is going to make it's way into CVS?
I notice that its auth only and you don't have any SASL security layer integrity or protection stuff, same as DIGEST-MD5. This is the point which I've got to and have been considering how to implement the 'integrity-proxy' (name coined from the Colin Walters patch) part of things. Work on this would have implications for mech-digest-md5.c as well.
Want to discuss ideas?
Timo, do you have any ideas on a good way to implement this?
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
- keep the imap-login process around but have it re-exec as the filter (would be running as login_user, probably not ideal)
On Wed, Oct 19, 2005 at 02:11:14PM +0100, pod@herald.ox.ac.uk wrote about 'Re: [Dovecot] [PATCH] Support for GSSAPI SASL Mechanism':
"JV" == Jelmer Vernooij jelmer@samba.org writes: JV> Attached is a patch against current CVS that adds support for the JV> GSSAPI SASL mechanism. It was written from scratch, after reading JV> the patch from Colin Walters against a much older version of JV> dovecot. I too have been working on getting a working GSSAPI patch against current CVS and have taken a similar approach. Yeah, Timo mentioned there was someone else working on a new patch when I first talked to him yesterday evening, but I already had everything working by then, except for the configuration options, so I decided to go ahead. What's the status of your patch?
Any idea if this is going to make it's way into CVS? I hope so :-)
I notice that its auth only and you don't have any SASL security layer integrity or protection stuff, same as DIGEST-MD5.
I've focussed on authentication only for now since it keeps the patch small and readable (and thus is hopefully more easily accepted into CVS). Just authentication is sufficient for a lot of people.
Integrity and protection support can always be added later on by adding a couple of functions in mech-gssapi.c (and the right infrastructure in dovecot).
This is the point which I've got to and have been considering how to implement the 'integrity-proxy' (name coined from the Colin Walters patch) part of things. Work on this would have implications for mech-digest-md5.c as well. Yeah, that's a tricky. Especially when doing it in a way that has to be usable for more mechanisms.
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().
- keep the imap-login process around but have it re-exec as the filter (would be running as login_user, probably not ideal)
Cheers,
Jelmer
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.
"TS" == Timo Sirainen tss@iki.fi writes:
TS> In any case login/master processes wouldn't have to know anything
TS> about GSSAPI there, they'd just forward parameters from
TS> dovecot-auth blindly (I think master already does?).I'm not sure it does. I've tried handing back gssapi_qop, gssapi_max_size and gssapi_context as extra fields but I've not obviously seen those fields available in the imap process.
TS> plus side there is that if there happens to be any exploitable
TS> security holes in GSSAPI library, login process would be running
TS> in chroot and attacker wouldn't get direct access to anyone's
TS> mails.Couldn't this be a downside also? The login process would hold the user credentials but is running as the same user as all the other imap-login/proxy processes - if there were a way to get at the process address space of the other processes one could steal the credentials. I can't decide if this is just a theoretical possibility or a credible risk.
On Wed, 2005-10-19 at 15:21 +0100, pod@herald.ox.ac.uk wrote:
"TS" == Timo Sirainen tss@iki.fi writes:
TS> In any case login/master processes wouldn't have to know anything TS> about GSSAPI there, they'd just forward parameters from TS> dovecot-auth blindly (I think master already does?).I'm not sure it does. I've tried handing back gssapi_qop, gssapi_max_size and gssapi_context as extra fields but I've not obviously seen those fields available in the imap process.
Hmm. If userdb returns unknown fields, they are just put to environment variables. That's why setting "quota" in userdb reply reaches the quota plugin even though nothing in Dovecot's code knows about it.
TS> plus side there is that if there happens to be any exploitable TS> security holes in GSSAPI library, login process would be running TS> in chroot and attacker wouldn't get direct access to anyone's TS> mails.Couldn't this be a downside also? The login process would hold the user credentials but is running as the same user as all the other imap-login/proxy processes - if there were a way to get at the process address space of the other processes one could steal the credentials. I can't decide if this is just a theoretical possibility or a credible risk.
Those processes are treated as setuid-processes by kernel, so they can't touch eachothers unless there is some kernel bug.. AFAIK the only thing they could be able to do to eachothers is to send signals.
"TS" == Timo Sirainen tss@iki.fi writes:
TS> Those processes are treated as setuid-processes by kernel, so they
TS> can't touch eachothers unless there is some kernel bug.. AFAIK the
TS> only thing they could be able to do to eachothers is to send
TS> signals.Is this true of all kernels or just linux kernels?
On Thu, 2005-10-20 at 12:58 +0100, pod@herald.ox.ac.uk wrote:
"TS" == Timo Sirainen tss@iki.fi writes:
TS> Those processes are treated as setuid-processes by kernel, so they TS> can't touch eachothers unless there is some kernel bug.. AFAIK the TS> only thing they could be able to do to eachothers is to send TS> signals.Is this true of all kernels or just linux kernels?
All.
"JV" == Jelmer Vernooij jelmer@samba.org writes:
JV> Yeah, Timo mentioned there was someone else working on a new patch
JV> when I first talked to him yesterday evening, but I already had
JV> everything working by then, except for the configuration options,
JV> so I decided to go ahead. What's the status of your patch?Similar to yours I think. Auth only working. I didn't do a keytab config var addition. I was holding off until I'd got at least a skeleton/sketch of how to put in the SASL security layer.
JV> I've focussed on authentication only for now since it keeps the
JV> patch small and readable (and thus is hopefully more easily
JV> accepted into CVS). Just authentication is sufficient for a lot of
JV> people.Agree.
JV> You'd have to export the GSS security context from the login
JV> process to the user process somehow, but that shouldn't be a
JV> problem with gss_{ex,im}port_sec_context().I've been trying to work out how to propagate the exported blob safely through the dovecot process hierarchy. I'm not entirely happy about it appearing in the process environment, for example, since that may not be private enough.
I believe there is a significant privacy issue with the recently posted updated GSSAPI patch when used on multiuser systems (indeed this problem is present in the previous patch as well).
The username, and consequently the uid that the imap process is eventually run as, is taken from the authorization id in the (unwrapped) buffer supplied by the client as part of the SASL security layer negotiation.
The short of it is that with the patch as it stands user1 can authenticate as user1 but supply user2 as the authorization id and dovecot will fire up an imap process running as user2 looking at user2's mail.
I'm attaching a patch that I believe fixes the immediate problem but it is really only a bandaid over more general SASL issues.
The patch does the following:
- Adds in a QOP negotiation flags enum (somewhat cosmetic really)
- Renames src_name in gssapi_auth_request to authn_name and adds authz_name
- Adds a helper function to import a gss_name_t from a buffer
- Imports the authorization id (authz_name) and compares it with the authentication id (authn_name). If they are different authentication is declined.
I'm not entirely happy that the username passed back from the auth process is still copied from the authorization id buffer because it feels like the username should come from gss_display_name. Unfortunately that will tend to return names like user@REALM which opens up another can of worms and is too much for my little brain to cope with right now.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
pod@herald.ox.ac.uk wrote:
I believe there is a significant privacy issue with the recently posted updated GSSAPI patch when used on multiuser systems (indeed this problem is present in the previous patch as well).
The username, and consequently the uid that the imap process is eventually run as, is taken from the authorization id in the (unwrapped) buffer supplied by the client as part of the SASL security layer negotiation.
Arrgh!! - stupid of me not having thought of this. It's actually in the internet draft...:
"[..] and the remaining octets as the authorization identity. [..] The server must verify that the src_name is authorized to act as the authorization identity. After these verifications, the authetnication process is complete."
Thanks for pointing this out.
I'm attaching a patch that I believe fixes the immediate problem but it is really only a bandaid over more general SASL issues.
If you'd want to use dovecot's SASL for more advanced stuff, then maybe, yes. I wouldn't consider this patch a bandaid though (that sounds hackish).
I'm not entirely happy that the username passed back from the auth process is still copied from the authorization id buffer because it feels like the username should come from gss_display_name. Unfortunately that will tend to return names like user@REALM which opens up another can of worms and is too much for my little brain to cope with right now.
No, what you did here is correct. The second name is the one that should be returned to dovecot (see the internet draft).
Cheers,
Jelmer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDV8SCPa9Uoh7vUnYRAlvxAJ9I+1teJqvx0A0iAg8T4kJtGerHIgCdG0F7 OHiTxqwS4xwuJ8pN75+r52w= =Iql/ -----END PGP SIGNATURE-----
participants (3)
-
Jelmer Vernooij
-
pod＠herald.ox.ac.uk
-
Timo Sirainen