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 at 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
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. -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
On Wed, Oct 22, 2014 at 9:32 PM, James B. Byrne <byrnejb> 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?I guess you first need to decide what/who are you protecting your email from. If we are speaking about somebody entering into the datacenter and stealing/cloning a disk containing your users' emails, the luks solution described by Digimer should work fine. If you want to protect sensitive users of your organization (HR director, CFO, etc) from your own IT admins, things get complicated easy :-) . ecryptfs can do a per-user file-based encryption but it doesn't really handle multi-user environments. If your /home/user1 is mounted from a ecrypfs filesystem, nothing prevents root / sudo'd processes from picking files from a certain user. For the latter I'd suggest using PGP -- although instructing users to handle the complexity of client-based encryption is another huge task. My 0.02?
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 at 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 at 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 at centos.org > http://lists.centos.org/mailman/listinfo/centos-- -Martin
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? -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ----- Original Message -----> From: "James B. Byrne" <byrnejb at harte-lyne.ca> > To: centos at centos.org > Sent: Wednesday, 22 October, 2014 20:32:32 > Subject: [CentOS] Q. LUKS or ecryptfs-utils ?> 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 at 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 at centos.org > http://lists.centos.org/mailman/listinfo/centos
--On Wednesday, October 22, 2014 03:32:32 PM -0400 "James B. Byrne" <byrnejb at harte-lyne.ca> wrote:> 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.Regarding the USB comment, see CentOS 5.4+: <http://www.gno.org/~gdr/sysadmin/centos/5.4/usb-crypto-key.html> CentOS 6.5+: <http://www.gno.org/~gdr/sysadmin/centos/6/usb-crypto-key.html> I don't have a solution for CentOS 7 yet. If someone comes up with one, please drop me a note. Devin