On 30-05-14 22:42, Jean-Michel Pouré - GOOZE wrote:
> OK, let's talk about attack scenarios:
Now we're talking :-)
> OKay, an attacker with a rootkit knows "db" password and has root
> access.
Would that be prevented by putting a proxy like nginx in front of the
mail service, on an isolated vps or lxc container?
> Now, let's face a second situation, where the attacker has discovered a
> leak in dbmail (or in the OS) and is able to change interactively these
> few bits. The result would be the same.
Agreed. Though I think this might be remedied (at least partially) by
putting a proxy in front of dbmail, and running dbmail as a
non-privileged user on a high port. (Again, running dbmail on a
dedicated VPS or container).
Using a proxy would make it *much* harder to break into the dbmail host,
I suspect. But if you gain shell on the proxy, you can use that to break
into dbmail. It's not inconceivable, so let's assume it's possible.
> Now, let's face a third situation where dbmail would only have access to
> a limited schema, protected by a PostgreSQL user/password, as I
> mentioned earlier. Even in case of a leak, the attacker would only be
> able to read his own mail. In case of a rootkit, the main "db" password
> is only known by administrator and the attacker only knows his own
> password.
That would add only one additional layer. First you'd have to break the
proxy, next the dbmail host, and lastly the postgresql host.
> I don't want to mean that dbmail is broken in C code programming (it
> seems well-written), but in database design, for sure. dbmail should run
> only on a server with enhanced security, memory protection like grsec
> patch and even that is not secure given that security is stuck into
> dbmail and should rely more on PostrgeSQL (or MySQL).
Assuming those are more secure. Which is probably a safe assumption, but
still an assumption.
> The main modifications needed are:
> * No sharing of emails. CC and BC should result in a copy in the
> database.
Not much changes needed there since the shared noting storage is implied by:
> * Database user level security relying on either schemas or table prefix
> (which is the same).
>
> Do you know whether MySQL supports schemas like PostgreSQL or Oracle do?
I don't think MySQL or MariaDB support it. At least I can't find
anything related to it.
> The problem with MySQL development is that at some point, you usually
> bump on non-standard features and you are bound to support the worst
> database in the world, an many people love it, so you have to emulate
> what comes standard with PostgreSQL or Oracle. And in the end, you are
> not even sure whether MySQL still exists as a community, as it is being
> bought and sold all the time. i understand the rules of supporting
> MySQL, but is there schema support on latest MySQL versions or do we
> have to emulate that with table prefix?
It looks like it. With MariaDB there is some hope for full SQL-99
compliance, but I'm not holding my breath.
--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, github, linkedin
www.nfg.nl/i...@nfg.nl/+31.85.877.99.97
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
