[Dovecot] Login processes and a new performance/security compromise [was: Re: pre-1.0.rc27: Index and mbox fixes]

[Timo Sirainen]

On Sun, 2007-03-11 at 09:51 -0700, Troy Engel wrote:
> #login_process_per_connection = yes
> 
> ...with all the notes about security ans so forth. The question is 
> though what's a best recommended practice for efficiency and speed?

I was just updating my master/config/logging rewrite code, which has
been almost-working for last two years or so. Then I had an idea:

The biggest performance problem with login_process_per_connection=yes is
creating, initializing and destroying the process.
login_process_per_connection=no's problem then is that the attacker can
steal other users' passwords and TCP sessions (if there ever is a
security hole in the login process code or in OpenSSL).

If a login process is handling only a single connection at a time that
takes care of the TCP session spying/stealing. Then if all the memory
allocations are always cleared before freeing the memory (or old memory
when realloc()ing), that takes care of the password stealing as well,
since there should be nothing important left in the memory from the
previous user's session.

I can think of two potential problems: the stack and the memory
allocated by libraries. Luckily OpenSSL can be told to use different
memory allocation functions, and I don't think there are any other
library calls made that could leave anything important into memory. As
for stack, I don't think I ever store anything important there.

Benchmarks show that this works pretty nicely. I get around 1350-1400
connections/second. Using multiple connections/process gives 1450-1500
connections/second. Cleaning the memory vs. not cleaning it doesn't seem
to make any noticeable performance difference.

Hmm. Except there's also Dovecot's data stack which I almost forgot.
I'll add a new data_stack_clean() function to be called whenever a
client is deinitialized.

The benchmarks are with the rewritten code. The same behavior can be
done with v1.0 by setting login_max_connections = 1, although only CVS
HEAD has the cleanup code. Looks like I can get only 1150-1200
connections with CVS HEAD both with login_max_connections=1 and with a
higher value. So looks like my rewrite is actually faster even though it
requires doing UNIX socket connections to log and config processes.

Oh, and as for when the rewrite is in CVS, I'm not really sure. I'm
still wondering if I should put it there soon and make the release after
v1.0 be v2.0, or if I should first stabilize the current new CVS HEAD
features (which shouldn't take too long), do a v1.2 release and only
then put this code to CVS and make it v2.0..
-------------- 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/20070318/85803ef7/attachment-0001.pgp