hi, what do you tyhink about it? especially the faq comment about dovecot? http://www.bincimap.andreas.hanssen.name/
-- Levente "Si vis pacem para bellum!"
[oh well, let's cc the author as well]
On Tue, 2003-02-04 at 13:43, Farkas Levente wrote:
hi, what do you tyhink about it? especially the faq comment about dovecot? http://www.bincimap.andreas.hanssen.name/
That's interesting. Haven't noticed it before. Author's name is actually familiar from imap mailing list :) Initial impressions:
It uses C++, so why is it still using sprintf() in a few places, just waiting to be exploited? That alone actually makes me question his "C++ security experience" (well, that's not C++ exactly..). The ones in COPY and APPEND handling actually can cause buffer overflows if host has long enough hostname.
Says it's a replacement for Courier IMAP, and the design looks that way too. Currently at least maildir-specific (there was some empty mbox dir though) and without any kind of smart indexing, meaning it's quite likely close to Courier's performance.
I don't really get his comments about TCP wrappers. Meaning that I do network I/O instead of letting inetd handle it? That's only minimal part of the code and I'd say it has near-zero possibility for any security related problems, or any kind of all really. Well, of course doing it in inetd allows /etc/hosts.deny and such.
I guess his server runs as root until user is authenticated. That requires that all IMAP commands check properly that they're not run before authentication, that everything that is run before authentication must have perfect security or attacker can get roots. SSL communication is likely also done as root.
That's very different from Dovecot's design, where login process has been designed so that even in case of a security flaw (eg. SSL library), there's no way for the attacker to do _anything_ before being properly authenticated (chrooted, non-privileged user, only access to communicate with auth process via pipe but no way to get other users' passwords or anything). Post-login SSL communication is also done by the same login process, so that exploiting SSL library bugs even then won't do any good.
It wouldn't be too difficult to allow Dovecot to be run from inetd, but I don't think there's much point. It's certainly less secure since it initially requires roots.
Hmm. What else .. I would have expected C++ code to be more .. prettier. It's 10k lines count may be partially because of C++ and using lex instead of writing own parsers, but I think it's mostly because it doesn't really do much. Plaintext authentication + maildir + IMAP4rev1 is pretty much what it does now, without anything special in design or implementation (except for being C++). Very much like Courier or UW imapd.
Wait a sec, so dovecot isn't supposed to run from inetd or
xinetd? I'm just wondering cause that's how I've been running it for about 2 months. If not then how "should" I be running it?
./disco
P.S. Thanks for a slick imap program. I've been using it and am very happy with its performance and features. Cheers Timo.
-----Original Message----- From: dovecot-bounce@procontrol.fi [mailto:dovecot-bounce@procontrol.fi] On Behalf Of Timo Sirainen Sent: February 4, 2003 8:36 AM To: Farkas Levente Cc: dovecot@procontrol.fi; andreas@hanssen.name Subject: [dovecot] Re: bincimap
---[ snip ]---
It wouldn't be too difficult to allow Dovecot to be run from inetd, but I don't think there's much point. It's certainly less secure since it initially requires roots.
---[ snip ]---
On Tue, 2003-02-04 at 18:21, Rick Stewart wrote:
Wait a sec, so dovecot isn't supposed to run from inetd or xinetd? I'm just wondering cause that's how I've been running it for about 2 months. If not then how "should" I be running it?
Uh. Have you set it to run the imap binary? It doesn't require any authentication then, just connecting to the port gives direct access. Not a good idea :)
You should have run imap-master binary. Or dovecot binary in next version.
participants (3)
-
Farkas Levente
-
Rick Stewart
-
Timo Sirainen