On Tue, 2006-06-20 at 00:53 +0200, Marc Dirix wrote:
> It would be nice, although I understood from Paul sqlite backend
> isn't quite production ready,
I'm using it in production. It's going into flux to work with SQLite3
right now.
> if you'd have the time to write an howto on the wiki. With also the
> security considerations behind them. As I like to learn more about
> them, and to be able to add it to my considerations the next time I
> upgrade or install a new dbmail site.
I don't think it's wise in that situation because there lacks a certain
amount of infrastructure:
1. I handle logins myself- not DBMail. It's done with a relatively small
amount of C code.
2. After login, a unix domain socket is connected to ~user/.dbmail/
all logins run as an unprivileged user, chrooted into /var/dbmail-root/
3. Dbmail runs from supervise- one per user already attacked (via proxy)
to ~user/.dbmail/ and already chrooted, one user per database.
Unless it's run in this situation, DBmail+SQLite isn't any more secure
than DBMail is presently, and probably less so because it certainly uses
more memory, and the DBMail process needs to write to the filesystem.
> As is also my opinion, but that doesn't mean the administrator I was
> talking about equates security without breaches. I meant the
> administrator knows the probability that he is using programs with
> security breaches is about 1. If not his mailserver, his webserver is
> the second candidate.
Right. Except we can't say anything about probabilities with DBMail
until it's either privilege-separated or audited.
> As said we use dbmail for different purposes and therefor from
> different viewpoints, privilege separation is good for your setup, as
> it isn't for mine. Because I use a lott of company-level mailsetups.
> I need dbmail to be a *fast* backend to locations with a lott of
> shared mailboxes.
FWIW, DBMail in my setup bottlenecks at disk I/O and is about as fast as
PostgreSQL (perhaps even a little bit faster at some points).
> The point is, security and data intergrity *is* very important. But
> it shouldn't be the focuspoint at places where a better sollution is
> found outside dbmail. I.E. the sql injection: From what I understood
> has postgresql solved the security issue by implementating a patch to
> eliminate sql injection attacks. If this resolves the problem
> withouth changing dbmail than I think it is good to state a
> recommendation on the dbmail wiki/docs and don't patch dbmail.
No, bind parameters don't eliminate sql injection attacks. It makes a
certain kind quite difficult. The problem is escaping, and the
developers already think they _are_ escaping in all the right places.
MySQL's escaping rules are FAR more complicated than any other SQL
engine that I'm aware of, and more complicated than SQL92 required,
which was simply:
s/'/''/g
But MySQL's rules are more like:
s/(['\\"`])/\\$1/sg;
s/([\0-\017\177-\377])/sprintf("\\%03o",ord($1))/seg;
Although I'm pretty sure that's not entirely correct...
SQL injection is only one kind of attack- if DBMail can be controlled by
other means, a user (perhaps: an anonymous one) might have access to
_all_ mail, and might have access to damage all mail.
The only way to solve this is an audit. It wouldn't be enough to simply
use bind parameters everywhere- there might be other bugs...
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
