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-bounces@dovecot.org [mailto:dovecot-bounces@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?