LUKS disk encryption plugin

    • OMV 2.x
    • ryecoaaron wrote:

      doron wrote:

      Makes sense?
      Sounds great but how do you do that? The same system that mounts the filesystem with the key file in it (fstab) is going to try and mount the filesystem inside the LUKS container. This will fail since the container is not unlocked. You are supposed to be able to add disks containing key files in /etc/default/cryptdisks so they are mounted before the container is unlocked but I didn't have much luck with that.
      We might be talking about two different things.

      If you are thinking about auto-unlocking the root filesystem or any related FS's that are needed for the system startup, then you're obviously right. This is not what I'm referring to though. The containers I'm thinking about are data containers. They can be mounted at will, like the containers that are currently supported by the plugin.
      For those, I propose a new feature: configure the name (full path) of a key file, with which the container is encrypted. So long as they key file is absent, the status is as it is now (no unlocking). Once the file becomes available (say, a USB drive has been mounted), the container is auto-unlocked.
    • doron wrote:

      For those, I propose a new feature: configure the name (full path) of a key file, with which the container is encrypted. So long as they key file is absent, the status is as it is now (no unlocking). Once the file becomes available (say, a USB drive has been mounted), the container is auto-unlocked.
      That would sound like is just editing a single file ("/etc/crypttab"). I use similar setup, the keys are stored in a small virtual disk, that small disk gets unlocked and mounted at initramfs, then crypttab uses the keyfiles in the disk to unlock them. At the end of the boot i have a systemd unit to lock back the virtual disk containing the keys.
      For this to work i had to go little bit further an insert a initramfs script to manually unlock during boot the disk containing the keys.
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10
      telegram.me/openmediavault broadcast channel
      openmediavault discord server
    • subzero79 wrote:

      doron wrote:

      For those, I propose a new feature: configure the name (full path) of a key file, with which the container is encrypted. So long as they key file is absent, the status is as it is now (no unlocking). Once the file becomes available (say, a USB drive has been mounted), the container is auto-unlocked.
      That would sound like is just editing a single file ("/etc/crypttab"). I use similar setup, the keys are stored in a small virtual disk, that small disk gets unlocked and mounted at initramfs, then crypttab uses the keyfiles in the disk to unlock them. At the end of the boot i have a systemd unit to lock back the virtual disk containing the keys.For this to work i had to go little bit further an insert a initramfs script to manually unlock during boot the disk containing the keys.
      The difference is the trigger for unlocking. What I propose above "waits" for the keyfile to be present (poll, or event driven) and once available, does the luksOpen and triggers a mount. In contrast with your case, it can happen any time, even much later than boot time. The key can also be on a device that is not (yet) available at boot.
    • If the key drive mount is in fstab and crypttab points the key file in that mount path, systemd should take care from there, unlock and mount the drives.

      doron wrote:

      In contrast with your case, it can happen any time, even much later than boot time.
      In my case unlocking of all drives is happening in initramfs loading
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10
      telegram.me/openmediavault broadcast channel
      openmediavault discord server
    • doron wrote:

      subzero79 wrote:

      If the key drive mount is in fstab and crypttab points the key file in that mount path, systemd should take care from there, unlock and mount the drives.
      When?
      Boot time. Systemd can correlate all dependencies in between crypttab and fstab. I did a test on disk a few weeks ago that's why I know. I think I still have the vm I did that.
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10
      telegram.me/openmediavault broadcast channel
      openmediavault discord server
    • subzero79 wrote:

      doron wrote:

      subzero79 wrote:

      If the key drive mount is in fstab and crypttab points the key file in that mount path, systemd should take care from there, unlock and mount the drives.
      When?
      Boot time. Systemd can correlate all dependencies in between crypttab and fstab. I did a test on disk a few weeks ago that's why I know. I think I still have the vm I did that.
      Exactly. Which goes back to the original point of the recent discussion and the proposal. If the external drive on which the key resides is not available (yet?) at boot time, there will obviously not be any luksOpen or mount. If the drive is made available later (just for the sake of this discussion, assume an hour later) than boot time, one will need to manually do the steps or script them.

      So, if the plugin were to allow a config in which the key file is a file spec (on top of the current config options - passphrase and HTTP upload), and will do its thing when the file exists (and wait for it if it doesn't), we'll be able to achieve that.

      This allows for auto-mounting on one hand, and if the server is taken, or a hard drive needs to be replaced etc., data can not be recovered (unless the external drive carrying the key is taken too).
    • I just wanted to let you guys know about an error that occurred whilst installing a new OMW3 server. Since the problem was reproducible and occurred after another fresh install as well, here's what's happened:

      After a fresh install of OMV3 and update to the newest version (3.0.87 Erasmus) I tried to install the openmediavault-luksencryption 3.0.2 plugin via GUI. As soon as I hit Install the pop-up windows shows up telling me
      that the following packages will need to be installed cryptsetup-bin openmediavault-luksencryption... so the standard procedure. Only then, nothing happens.
      Even after waiting for several minutes, nothing happens.
      When reloading the page and trying to install the plugin again, it'll tell me apt-get is obviously still running in the background - Error: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?


      So I log in via ssh and have a look:

      Shell-Script

      1. ps aux | grep apt





      I now can see the process:

      Shell-Script

      1. root 5487 0.0 0.0 4336 808 ? S 21:46 0:00 sh -c export PATH=/bin:/sbin:/usr/bi n:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; export DEBIAN_FRONTEND=noninteractive; apt -get --yes --force-yes --fix-missing --allow-unauthenticated --reinstall install openmediavault-lukse ncryption 2>&1



      It seemed to have stopped working. I can kill it using kill 5487 (the process number) - but when trying to install LUKS yet again the same will happen over and over.
      The logs of OMV aren't helpful at all - they're just empty (or I'm too dumb to pick the right one or choose the right settings)

      Anyways, so I tried installing using ssh (BTW apt-get -f install didn't help either) and now I do get an error message (sorry, it's in German):

      Shell-Script

      1. root@Server:~# apt-get --yes --force-yes --fix-missing --allow-unauthenticated --reinstall instal l cryptsetup cryptsetup-bin openmediavault-luksencryption
      2. Paketlisten werden gelesen... Fertig
      3. Abhängigkeitsbaum wird aufgebaut.
      4. Statusinformationen werden eingelesen.... Fertig
      5. Vorgeschlagene Pakete:
      6. dosfstools keyutils
      7. Die folgenden NEUEN Pakete werden installiert:
      8. cryptsetup cryptsetup-bin openmediavault-luksencryption
      9. 0 aktualisiert, 3 neu installiert, 0 zu entfernen und 17 nicht aktualisiert.
      10. Es müssen noch 41,0 kB von 376 kB an Archiven heruntergeladen werden.
      11. Nach dieser Operation werden 1.582 kB Plattenplatz zusätzlich benutzt.
      12. Medienwechsel: Bitte legen Sie das Medium mit dem Namen
      13. »Debian GNU/Linux 8 _Jessie_ - Official Snapshot amd64 LIVE/INSTALL Binary 20170706-22:03«
      14. in Laufwerk »/media/cdrom/« ein und drücken Sie die Eingabetaste (Enter).
      15. Holen: 1 https://dl.bintray.com/openmediavault-plugin-developers/erasmus/ jessie/main openmediavault- luksencryption all 3.0.2 [41,0 kB]
      16. Medienwechsel: Bitte legen Sie das Medium mit dem Namen
      17. »Debian GNU/Linux 8 _Jessie_ - Official Snapshot amd64 LIVE/INSTALL Binary 20170706-22:03«
      18. in Laufwerk »/media/cdrom/« ein und drücken Sie die Eingabetaste (Enter).
      Display All

      So somehow OMV wants to access /media/cdrom and look for Debian GNU/Linux 8 _Jessie_ - Official Snapshot amd64 LIVE/INSTALL Binary 20170706-22:03.
      What the..?
      OK, so after some googling around I found where to look for the setting (velocihost.net/clients/knowled…d--on-your-Linux-VPS.html)


      Source Code

      1. nano /etc/apt/sources.list
      (Call me names, I hate vi and love nano)

      So in there I just prefix the deb cdrom: line with # - save and exit nano.

      ...and afterwards, LUKS encryption installation was no problem whatsoever.

      Maybe that'll help somebody else.
      I still wonder why it's trying to access a non-existent CDROM at all...
    • This isn't a problem with the plugin. You must have done something different with your install (installed Debian then OMV? or installed OMV without a network connection).
      omv 4.0.6 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • KOENICH wrote:

      The problem didn't occur with any other plugin.
      That is just coincidence. The plugin doesn't add the repo it is in. omv-extras does. And the none of the omv-extras plugins including omv-extras itself adds/removes/enables/disables the cdrom sources.list entry.
      omv 4.0.6 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • KOENICH wrote:

      I don't believe in coincidence, at least not in this matter. I believe in reproducibility which I proved.
      It doesn't matter if you believe in coincidence. I know this plugin very well. What happened is you reproduced your error. How can a plugin that doesn't touch anything in /etc/apt/sources.list add the cd-rom entry to /etc/apt/sources.list??
      omv 4.0.6 arrakis | 64 bit | 4.12 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • fyi:
      Due to system errors on my system drive I just reinstalled the entire system, this time with the current 3.0.86.
      Exactly nothing else was changed, so the exact same setup as above, same installation procedure - this time LUKS encryption installation was no problem whatsoever. So the problem must have related to do with 3.0.82 I used before (see above).