Q. LUKS Or Ecryptfs-utils ?

Home » CentOS » Q. LUKS Or Ecryptfs-utils ?
CentOS 7 Comments

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.

7 thoughts on - Q. LUKS Or Ecryptfs-utils ?

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

    /dev/sda1 – /boot (normal ext4 partition)
    /dev/sda2 – LVM PV – VG:
    lv_swap -> luks ->
    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.

  • 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

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