On 22/10/14 03:32 PM, James B. Byrne wrote:

I am now investigating encrypting our IMAP user spool files. Does anyone have experience with handling encrypted data stores using either or both of the subject methods and would care tio share their observations? Which is the preferred method (I know: it depends, but on what?)? What administrative pain does each cause?

Our IMAP host is a KVM guest so spinning up a duplicate and simply copying the data to an encrypted device or filesystem is not a very big deal. We can live with manually mounting the file system and providing a pass-phrase at boot. we are also looking into a semi-auto USB based solution to that issue.

Our mail server has used LUKS encryption for the <swap> and / partitions for a while without issue. I use:

/dev/sda1 - /boot (normal ext4 partition) /dev/sda2 - LVM PV - VG: lv_swap -> luks -> <swap> lv_root -> luks -> ext4 -> /

Running on CentOS 6.x, postfix/dovecot. Authentication DB is another server with similar LUKS config. Both are KVM VMs. As you mentioned, I do need to enter the passphrase on boot. I have an alert system that warns me if a VM reboots unexpectedly.

Hello James,

As you already said, the decision on which method use depends on what you want to accomplish so lets take a brief look at how these encryption methods works:

- dm-crypt with LUKS: the encryption works at partition-level so the only way to use it is to first create a partition, then encrypt it and only then mount it and install your system or start filling with stuff. - eCryptFS: this method creates an encrypted file wherever you want in your system so you can transparently mount it and start using it as if it were just any other directory.

Cons: dm-crypt/LUKS: a) if your root directory is encrypted you will need to enter the decryption passwd every time you boot the system. b) You can't just encrypt files or directories, as I explain above you need to first create an encrypted partition and then mount it. c) Depending the filesystem setup you chose you might not be able to resize your LUKS partition once it is created (mostly this applies to Btrfs) so be sure about what you are doing; using an LVM+pick_your_preferred_FS setup should be okay though.

eCryptFS: a) Access times are AWFUL but this is absolutely understandable because the way this encryption works: whenever you put stuff on this 'directory' (or remove stuff from it) it is written to/from a single file... most problems arises when dealing with lot of I/O operations or copying big files into it, which is plain painful; however I yet have to see how it performs on newer SSD drives, so far I only tested eCryptFS on traditional mechanical disks. b) If you decide to remove the eCrypt file but you don't carefully follow developers' instructions it will be HELL -- believe me, I was there, my own fault of course.

Pros: dm-crypt/LUKS: a) The encryption/decryption is much, much, MUCH faster than with eCryptFS and uses fewer resources, both CPU cycles and disk I/O operations -- it's likely you won't notice the impact at all. b) While you will need to enter a passphrase to decrypt your root partition every time you boot - should you decide to encrypt it - that isn't true for the rest of your dm-crypt/LUKS volumes: you can use a password file to automatically decrypt your media thru /etc/crypttab, which is parsed before /etc/fstab: crypttab first decrypt all the volumes as instructed and then handles the mounting operation to fstab. b) Because of the above, you could easily create a new encrypted partition and mount it automatically.

eCryptFS: a) Creating new encrypted storages is as trivial as counting 1, 2, 3.

I'm sure more experienced admins can help you better understand these encryptions methods, I just wanted to give you an overview of them.

HTH! -Martin

On Wed, Oct 22, 2014 at 4:32 PM, James B. Byrne byrnejb@harte-lyne.ca wrote:

I am now investigating encrypting our IMAP user spool files. Does anyone have experience with handling encrypted data stores using either or both of the subject methods and would care tio share their observations? Which is the preferred method (I know: it depends, but on what?)? What administrative pain does each cause?

Our IMAP host is a KVM guest so spinning up a duplicate and simply copying the data to an encrypted device or filesystem is not a very big deal. We can live with manually mounting the file system and providing a pass-phrase at boot. we are also looking into a semi-auto USB based solution to that issue.

-- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos