LUKS disk encryption plugin

  • About LUKS
    LUKS is the standard for Linux hard disk encryption. By providing a standard on-disk-format, it does not only facilitate compatibility among distributions, but also provides secure management of multiple user passwords.In contrast to existing solution, LUKS stores all setup necessary setup information in the partition header,enabling the user to transport or migrate his data seamlessly.
    See also: https://gitlab.com/cryptsetup/cryptsetup


    About the plugin
    This plugin provides for basic manipulation of LUKS-encrypted devices in OpenMediaVault; encrypted devices can be created, destroyed, opened (unlocked/mounted) and closed (locked/unmounted). Keys (regular passphrase and key files) can be added, changed, and removed. The header (which contains the master key and they keys (passphrases) used to unlock it) can be backed up and restored.
    The plugin is designed to work with bare disks, the workflow being that you encrypt a raw disk (e.g. /dev/sdb, though you could also encrypt a RAID device, LVM logical volume, or existing partition). When the encrypted disk is unlocked, a device mapper device is created that provides access to the decrypted disk (they are currently named by appending '-crypt' to the devicename, e.g. /dev/mapper/sdb-crypt). Filesystems can then be created on top of this and used throughout the rest of OMV as normal.


    How to install
    To install the plugin, first install the OMV Extras plugin, then you can install openmediavault-luksecnryption from the Plugins section of the WebGUI. After installation, a new section, 'Encryption' appears under Storage (after Physical Disks and S.M.A.R.T.).

    Usage notes
    Devices must be unlocked via the WebGUI (select the device, click the 'Unlock' button and enter the passphrase), this means that they will (currently) remain locked at boot until manually unlocked. Services such as SMB/CIFS using shared folders on the encrypted disk will not work properly and may give errors about missing filesystems until the disk is unlocked, but will usually work fine after unlocking without any further need to restart.
    Adding and removing keys
    You can have up to 8 keys (passphrases) per device. Take care when removing removing passphrases - the GUI will check before proceeding, but it will allow you to remove the last key. If you do this, the device will be rendered useless as you will be unable to unlock it.
    Which leads on to...
    Backing up and restoring the header
    The header on a LUKS-encrypted device contains details of the encryption method and cipher, and also the master key needed for en-/decryption, itself encrypted by up to 8 passphrases, stored in key slots 0-7. It is advisable to make a backup of the header whenever you create an encrypted device or add, remove or change any of the passphrases. If the header or any of the key slots become corrupt (or you accidentally remove all the keys! - see above), you can restore the header from a backup, which will restore the passphrases as they were in the backup.


    Future plans
    Support for automatic unlocking at boot is planned.


    Dos and Don'ts
    Do...

    • Make a backup of the header when you create an encrypted device and every time you add/change/remove keys. Store it somewhere else - not on the encrypted drive!
    • Consider adding multiple keys, i.e. one that you use regularly especially if you find yourself changing it often, and one to keep in 'escrow' as an emergency
    • Take care accessing the WebGUI over unencrypted channels (plain HTTP), especially if operating remotely - the keys are transmitted in the clear over the network
    • Understand the limitations of encryption (see About encryption, below)

    Don't...

    • Restore the same header to multiple devices - it creates a point of single weakness in terms of encryption, and might cause problems in the future for automatic unlocking at boot
    • Remove all the keys from a device (unless you know what you're doing) - it renders the device useless as you can't unlock it again
    • Overwrite the header of a device (e.g. with disk partitioning software) - whilst you can restore the header from a backup, if you write further into the disk than the end of the header (2 MiB), you will be overwriting your actual data


    About encryption (caveats)
    The most useful aspect of whole disk encryption in this way is that you can dispose of the disks without needing to wipe them - just destroy the key and the data is irretrievable.
    It can also protect against data access in the case of theft of your NAS - the power will usually necessarily be cut to a stolen device, locking the disks. Except, of course if you are automatically unlocking the disks at boot time (not currently an option in the plugin), using a key that is necessarily stored somewhere accessible (e.g. on the OS drive).
    Note that even if you don't do this, every time you upload a key file via the WebGUI, it is written to disk (/tmp) temporarily. A determined attacker might be able to recover the contents of the key file even after it has been deleted. The plugin attempts to ameliorate against this by securely deleting (shredding) uploaded key files, but even this is not 100% foolproof. You can take further steps by moving /tmp to a tmpfs in RAM, rather than on-disk, or also by encrypting the OS drive. Both these things are beyond the scope of this guide. Of course, these are corner cases - whole disk encryption is reliably secure for most cases.
    Of course, encryption cannot protect against an attacker who has access to your live system - the data on the disks are necessarily decrypted when the system is running!



    Support
    Please report issues on GitHub (https://github.com/OpenMediaVa…ult-luksencryption/issues), or use this thread for discussion/support/problems with the plugin.

  • Thank you a lot for releasing this plugin. I am new to OMV and just play around in a VM since a few days. After installing your plugin, I get the following error message in my browser console:
    ext-all.js:22 Uncaught Error: Ext.Loader is not enabled, so dependencies cannot be resolved dynamically. Missing required class: OMV.workspace.window.TextArea


    Clicking on "Encryption Management" does not work, nothing happens except that the following error message appears:
    ext-all.js:22 Uncaught TypeError: Cannot read property 'substring' of null


    What am I missing? The installation went fine I guess:


    Uninstalling got me more errors:
    http://192.168.178.3/js/omv/module/admin/storage/luks/Containers.js Failed to load resource: the server responded with a status of 404 (Not Found)
    http://192.168.178.3/js/omv/module/admin/storage/luks/Luks.js Failed to load resource: the server responded with a status of 404 (Not Found)


    The uninstall log:

  • Hi,


    I'm not sure what is wrong with your installation, but I have tested this by creating a fresh install of OMV in a VM, updating, installing the OMV Extras plugin, then uploading and installing this encryption plugin, and it worked fine, I could create, destroy, lock and unlock encrypted disks (n.b. there is a problem with applying the configuration which gives an error, but since that 'application' is just a dummy that doesn't do anything at the moment you can just click revert to get rid of the 'needs applying' message banner).


    From the look of your errors, it sounds like there is something wrong with your OMV installation, in that the WebGUI is having trouble loading core files. As you are also testing in a VM, I suggest you trash and recreate your OMV installation. If you need more help debugging this installation, please post the steps you have done so far in installing, updating, etc.

  • Ensure that all required files are declared at the top of the JS file. Keep in mind that the file loading order might differ on various systems. So on your system a required file is loaded before the Luks.js, on other systems this might be not the case, so an error is thrown by the ExtJS framework.
    For the moment there is no better solution. Maybe when upgrading the framework to a new version (and a rewrite of code is necessary) we will switch to dynamic loading.

  • Ah, good to know. However, in this case I tested on a fresh install of OMV, with only this plugin (after OMV Extras) installed. So the only thing I can think of is that you (ottoman) don't have the omv-extras plugin installed?


    P.S. votdev, please can you add me to the developers' forum.

  • Nice a encryption plugin!


    Perfect timing, sorta, FreeNAS 10.x development has dropped encryption support. I just finished setting up freenas last month after I learned of OMV not having any plugins. Time to prepare data migration again.

  • I've updated the first post to reflect the fact that the plugin is now (soon) available via the OMV Extras repository. Please use this thread if you have any problems/thoughts/or anything else to discuss about the plugin.


    I've added support for adding/changing/removing passphrases in this release (v1.0.1), and fixed some small bugs. Note: be careful when removing passphrases, the WebGUI asks if you are sure, but it will still let you remove the last passphrase (you can have up to 8), which renders the device useless!

  • Had to put this in Container.js the panel wasn't loading


    // require("js/omv/workspace/window/TextArea.js")


    I've never ever used encryption. I have a couple of question:


    As an example If you define one of the encrypted volumes to use as database folder for mysql (or any other service), in a reboot mysql won't start because it won't have access to the device right? is this a correct assumption since you have log in an unlock through the web?


    Is it possible to add like a usb device to hold the passphrase and unlock the drives at boot? I know is a security issue but I just want to know if is possible.

  • Had to put this in Container.js the panel wasn't loading


    // require("js/omv/workspace/window/TextArea.js")


    require issue fixed in 1.0.2 in repo now.


    Excellent, thanks guys. I didn't have that issue myself, although I understand loading dependencies with ExtJS can be a bit unpredictable, perhaps I had something else resident that was loading TextArea.



    As an example If you define one of the encrypted volumes to use as database folder for mysql (or any other service), in a reboot mysql won't start because it won't have access to the device right? is this a correct assumption since you have log in an unlock through the web?


    Is it possible to add like a usb device to hold the passphrase and unlock the drives at boot? I know is a security issue but I just want to know if is possible.


    It depends on the service, but probably correct. e.g. if it's a Samba share, the share is still visible via the network, but attempting to open it fails (because the underlying filesystem is not mounted). In this case simply unlocking and mounting the filesystem works, no need to restart Samba.
    I haven't used MySQL, I don't know if it will fail to start or start in some crippled way. I guess each service that relies on an encrypted device will need to be tested on a case-by-case basis.


    So at the moment, yes, you need to log in to the WebGUI and unlock after booting. This is the most secure setup, in that the disks are securely encrypted, e.g., in the event of theft, but it can also be inconvenient, I agree. It is possible to use keyfiles (on a USB disk or wherever) and then you can have a disk unlocked automatically at boot (you can also set a disk with a passphrase to unlock at boot, but then it will halt during boot to prompt you for the passphrase, which is probably not a useful setup for most OMV users). Keyfile and automatic unlocking support is planned for the plugin, but you can already do this yourself via the command line (indeed, this is my current setup).

  • New release, v1.1.0, incoming adds this feature (mounting filesystems when unlocking). It can also be disabled by setting OMV_LUKS_MOUNT_ON_UNLOCK to false in /etc/default/openmediavault.
    Header backup and restore is implemented.
    Small caveat, this version requires OMV v2.1.19 (or later), which is not yet released, but I presume will be soon (for those who want to override: it's only for a cosmetic feature, it will work on <2.1.19 just fine)

  • Whilst the intended workflow is, in keeping with the OMV approach, to encrypt whole disks and then create whole disk filesystems, this plugin should be tested with a variety of other situations, such as encryption on top of RAID, LVM on top of encryption, or possibly vice versa, and also working with encrypted partitions (created outside of OMV).
    Please report your experiences if you are testing any of these scenarios!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!