I think your problem can be more generically restated as:
- Untrusted users have access to the mailstore, eg employees who
maintain the server, attackers who break into the system as untrusted
user accounts
- There is some trusted process to get access to decryption keys and
largely this process is secure (obviously except attacks which succeed
to escalate to root, or if employees typically get root access)
- How to extend this secure key access process to dovecot
So Exchange offers this feature where you can encrypt the mail and grant
specific users access to decrypt subsets of the mail. This means that
employees managing the mail server may not have access to decrypt the
messages for their boss, etc (without at least using trickery to bypass
and escalate their privileges - of course this is always possible,
especially with physical access, but it reduces the attack surface)
Off the top of my head it seems like any attempts to do this using block
disk encryption layers substantially boil down to equivalent to standard
file permissions. eg adding ecryptfs on the mail store means you need to
prevent access to the mounted decrypted files, which given the mail
store is a long running process, is largely equivalent to just using
file permissions, MAC, grsec, etc to protect the dir?
Timo's suggestion to incorporate in Dovecot opens up possible solutions.
ie now files can be decrypted *as* they are required by the mail server.
decryption key can probably be stored in userdb without loss of privacy
(since if you can get the password for the account you can just pickup
the emails via imap?). Bonus marks if you design some encrypted key
store, but is seems challenging to add value here, possibly against more
specific attacks, eg you don't want your database DBA to be able to get
access to the decryption keys, hence a separate (simple) database just
for decryption keys moves the problem sideways.
Using Timo's filter this all seems very do-able, but performance will
obviously be impacted. Modern processers are very fast at certain types
of encryption opts though..?
I'm interested to see what you produce. Seems interesting, but as many
have already commented, it really only defends against a limited attack
surface and not at all if the dovecot process or root/dovecot user is
compromised. I think corporates would quite like this feature though
Ed W
On 28/10/2013 19:14, Douglas Mortensen wrote:
Currently our dovecot servers are on our webhosting linux boxes. We are using the
LAMP stack to host websites, and also doing email with postfix & dovecot on
these systems. We provide this as a hosting setup for 100+ accounts/websites on a
single server (a multi-tenant setup). Each customer has anywhere between 1-100
email accounts which Dovecot services.
If a customer has vulnerable PHP code on a website, some of these will allow a
remote file upload. I have seen cases where they upload a PHP script that is a
sort of web-based console/shell to the server (file-system, etc.). It provides
several tools which all run through the uploaded PHP script to try to brute
force and do other attacks. I've seen attempts at a root exploit. We've never
had a root exploit and any such case of a customer's site being hacked has been
easily contained by simple filesystem permissions being correct (and the fact
that we have apache setup to run all scripts as the user who is the owner of
the script files, which confines the script to that users' permissions). Still
nobody loves the idea of bad guys trying to hack on your box.
So.... given that type of scenario, if filesystem permissions weren't correct,
or some new exploit surfaced that allowed someone bypass or elevate to root,
then they could theoretically have access to the entire fileystem including
where emails are stored.
I hope to never have this sort of thing happen. We patch our systems regularly
and have other security measures we follow to prevent this. We also are
managing most of the PHP scripts customers use ourselves now and are updating
those for the CMS' and other systems proactively.
However, it would be nice to know that even if we were breached, the emails on
the server were encrypted and would be completely useless to an attacker.
This type of encryption is ideal and some regulations prefer (although don't
require) it.
-
Doug Mortensen
Network Consultant
Impala Networks
P: 505.327.7300
-----Original Message-----
From: dovecot-boun...@dovecot.org [mailto:dovecot-boun...@dovecot.org] On
Behalf Of Michael Orlitzky
Sent: Monday, October 28, 2013 11:52 AM
To: dovecot
Subject: Re: [Dovecot] Encryption solution for messages at rest
On 10/28/2013 12:02 PM, Douglas Mortensen wrote:
Hi,
We have clients with various security & compliance requirements.
Although not required, it would be ideal to have messages encrypted at
rest.
You can rule out a lot of the crazier options by answering the questions,
(a) What attack scenario do you have in mind?
(b) How will encryption help?
