[Dovecot] Encryption solution for messages at rest

[Ed W]

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