[Dovecot] Encryption solution for messages at rest

Michael Orlitzky michael at orlitzky.com
Mon Oct 28 21:49:09 EET 2013


On 10/28/2013 03:14 PM, Douglas Mortensen wrote:
> 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.

If an attacker gets root, the entire exercise is pointless, because he
can get the decryption key. So you "don't have to worry" about that case =)

A suggestion, not dovecot-related:

The web users -- in our case, www.example.com -- shouldn't have access
to anything outside of the web root. You can achieve this within PHP by
placing everything that the website will need under one directory, and
setting (in apache):

  php_admin_value open_basedir /var/www/$domain/$host/
  php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp
  php_admin_value session.save_path /var/www/$domain/$host/tmp
  php_admin_value sys_temp_dir /var/www/$domain/$host/tmp

Personally, I don't trust PHP at all, so we create a separate web user
for each vhost and run them under mpm-itk <http://mpm-itk.sesse.net/>.


> 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.

Who has access to the maildirs on your systems? On ours, everything is
owned by deliver:deliver, with mode 700 or 600. The dovecot 'deliver'
user is the one who reads and writes all mail. (It is in fact a misnomer
now that we use LMTP). You can achieve the same by setting mode=600
everywhere in dovecot.conf, but this depends on your setup.

Suppose someone gains access to the 'deliver' user. That user is the one
who reads and would decrypt the mail; therefore the attacker can read
the mail anyway. But if they don't gain access to the 'deliver' account,
what can they do? Barring incorrect permissions or a kernel bug, nothing.

The permissions are handled by dovecot, which ostensibly you trust. And
if there's a kernel bug, you have bigger problems.




More information about the dovecot mailing list