On Wed, 2006-06-21 at 16:53 -0500, Jim C. Nasby wrote:
> One possibility would be to have the database handle all authentication
> and requests via stored procs, and restricting the dbmail database
> account to only having access to those stored procs. Or you could use
> per-user authentication to the database, as someone else suggested.
> Whether either step is worth the trouble...
These procedures- if only abstract sqlish versions of IMAP commands, are
powerful enough to steal and destroy any users email.
If the procedures also did access control (e.g. the first parameter was
a session token, or a user/password pair), then it would only move the
problem- these procedures would need to be as bullet-proof as DBMail
needs to be.
Of course, SQLite lives in-core, so it can't offer any security there.
Not that I'm saying stored procedures aren't a good idea- they are, and
could probably simplify a lot of things in the long run, unfortunately,
I can't see them generally adding any security.
> Of course, it goes without saying that DBMail should be coded to reduce
> the likelyhood of any possibility of an attack.
I'm suggesting a further extension of that: DBMail should be coded to
eliminate the possibility of certain attacks succeeding:
* unauthorized theft of mail
* unauthorized destruction of mail
Eliminating other attacks (denial-of-service, password cracking,
unauthorized network use, unauthorized filesystem access, etc) is really
a lot more easily handled _outside_ DBMail.
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
