On Mon, 2006-06-19 at 16:22 +0200, Paul J Stevens wrote:
> Geo Carncross wrote:
>
> > So what you're telling me is that you think only developers of dbmail
> > should be weighing in on the subject of dbmail's security?
>
> That would be the death of dbmail.
>
> I'm no security expert at all, and afaik neither is Aaron. I'm just a
> guy who ran across dbmail a couple of years ago, liked it, but found it
> lacking in terms of performance, scalability, reliability and code
> quality. I've since invested deeply in addressing those issues without
> doing a complete rewrite, and have gained some compentency in C along
> the way which I didn't have before.
Since the whole %sdbmail_* thing went in and a "table prefix" was
afforded, I'm thinking it'd be a relatively slim set of changes to give
each mailbox it's own table(s) - just set the prefixes at login time,
and the value would be enormous: A complete audit of dbmail wouldn't be
necessary to provide hard/fast truths on DBMail's security.
Maybe the OpenBSD people can audit something big like DBMail (as they
did with Sendmail)- but I cannot. I _can_ help with privilege separation
as this is what I'm currently doing. My reasoning is pretty simple- I
just ask myself what is worse:
* Small possibility of user damaging their own mailbox, and any other
mailbox they have write access to, ZERO possibility of damaging anyone
elses' mailbox, ZERO possibility of stealing email from other users, and
ZERO possibility of gaining a machine account,
_OR_
* Small possibility of damaging every mailbox, small possibility of
stealing email from other users, and a small possibility of gaining a
machine account (with perhaps the ability to escalate that later).
I don't know as this is a 2.2 thing, or even a 2.4 thing, but it might
be useful to make it a 3.0 thing, because it'd pretty much make the
possibility of a certain special kind of headache just _go_away_. I like
solutions like that.
We'd also get some other benefits on the cheap:
* Removal of Access control code (moved into SQL)
* Easy to chroot and drop privileges
* Easy to set per-user resource limits
Not to mention the fact that only the privilege separating code needs to
be audited carefully, and not all of dbmail.
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
