On Wed, October 22, 2014 18:52, Nux! wrote:

Do you also run the hypervisor? Because if you are not, then the host can dump your guest's memory and retrieve the luks passphrase from there AFAIK. Who are you hiding from?

The issue is backstopping a physical security breach. We run the hypervisor host and have physical control over access to the hardware.

Should the storage device be removed from our premises by unauthorised means then we wish assurance that the data thereon is not readily accessible to anyone. We are also cognisant that it is conceivable that a external threat might find some way to scan/copy the data without actually removing the device physically. I am under the impression that encryption 'should' work to prevent 'drive-by' surveillance in that case as well, but I am not entirely convinced that is true.

I am starting with the mail spool because that is a fairly straight-forward case. Our mail spool is mounted at /var/spool/imap and is an LVM volume. We have sufficient surplus space to easily create an equivalently sized or even larger LVM as an encrypted whatever. I am not sure of the correct terminology in this case; device/partition/something else?

My thinking is that we set up an encrypted LV, take the imapd service down, copy the imap spool files and directory structure to the encrypted volume. Dismount both, remount the encrypted volume in place of the original and restart the imapd service. Is this a sound approach?

We may want to have the imapd service started manually after the encrypted volume is made accessible. If so then both actions probably belong in an admin script (to be written).