[Dovecot] [PATCH] Support for GSSAPI SASL Mechanism

[Timo Sirainen]

On Wed, 2005-10-19 at 15:21 +0100, pod at herald.ox.ac.uk wrote:
> >>>>> "TS" == Timo Sirainen <tss at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20051020/2a2701a9/attachment.pgp