Posts by doron

Quote from subzero79

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

Quote from subzero79

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?

Quote from subzero79

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.

Quote from ryecoaaron

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.

Quote from ryecoaaron

You can't guarantee the external storage device would be mounted in time to get the unlock file.

That depends on what you define as "in time". If the basic assumption is that we must mount early in the boot process, then indeed the key file won't be ready on time. However, if we instead assume that we "wait" for the file spec to become available, and once it is - we luksOpen and mount, this opens a new set of possibilities.

We can then even automount the external filesystem with the key over some directory, and wait for the designated key file to "appear". Until it does, - the encrypted file system is not available.

Makes sense?

Quote from ryecoaaron

It was but after some testing, I couldn't find a reliable way to do it with the key file being stored anywhere other than the OS drive (pretty much pointless). Since most people would probably want the key on a USB stick, I dropped the plan.

Umm, understood. Two comments still:

• To reliably work with an external storage device, wouldn't something like /dev/disk/by-uuid come handy?
• Agree with your main point - if the only key file location you can deliver is the OS drive, the feature would not be very interesting. That being said, even placing the key on the OS disk, which may seem pointless, might have some merit for some attack scenarios. For example, if all one cares about is that when they get rid of a drive (e.g. they replace a faulty one). data does not get exposed.

Quote from ryecoaaron

You can always create the luks device manually. What type of "full block" device is it?

It's one partition off of a RAID 5 array. And yes, that is what I did (create it manually).

Quote from ryecoaaron

There is a bug in the plugin where you can't add a key file if you used a passphrase to create it. If you use the key file first and then add a passphrase -or- all passphrases -or- all key files, it works fine. Not real high on my priority list to fix.

That would definitely explain it

BTW, I seem to recall that at some point we've discussed auto-open (unlock). E.g. specify a file path for a key file, which, if found, will auto-unlock and auto-mount the LUKS device. Is this on your list?

Thanks!

Hi folks,
Installed OMV 3.0.84 on a test system. Added the plugin and trying to create a new encrypted partition. I'm getting a failure, with the following details.

Apparently the plugin issues a "partprobe" against the device on which LUKS layer is being created, assuming it's a full block device. This clearly fails when the target is a partition...
Is there any way around it?

Thanks!

[EDIT]
1. I just noticed that this thread has an "OMV 2.0" label on it, so perhaps my question is somewhat out of scope?
2. I also noticed that trying to ADD a key which is a key file, fails cuz cryptsetup can't open the file (/tmp/php****...). I did manage to ADD a passphrase key and then CHANGE it into a key file
[/EDIT]

Error #0:exception 'OMV\Exception' with message 'export LANG=C; partprobe '/dev/md127p3'' in /usr/share/openmediavault/engined/rpc/luks.inc:387
Stack trace:
#0 [internal function]: OMVRpcServiceLuksMgmt->createContainer(Array, Array)
#1 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array(Array, Array)
#2 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('createContainer', Array, Array)
#3 /usr/sbin/omv-engined(536): OMV\Rpc\Rpc::call('LuksMgmt', 'createContainer', Array, Array, 1)
#4 {main}

Hi raisOr,

Yes, this appears like the more detailed (and accurate) version of what I schematically wrote. Thanks for correcting my cryptsetup syntax.
It also seems that if any step here is incorrect, it will let you know (fail) rather than break your array.

I would still strongly recommend testing it - I usually do it on a virtual OMV machine with several small v-drives, to clean up the plan.

Good luck,
Doron

Hi raisOr,

So I can't test this right now, which is why I strongly recommend that you try this on a small toy array, just to make sure it doesn't break anything.
I believe the correct sequence would be only slightly different than what you wrote:

1. Add the HDD into the RAID (mdadm)
2. Resize the LUKS device (yes, you need to do that):
cryptsetup resize /dev/mapper/<what>
By default this takes the full size of the underlying block device (the array), which is what you want.
3. Extend the ext4 file system to the full size of the LUKS device.

I believe this is all there is to it. Again, not tested; please try it on a test system.

While at it, I recommend you take a look at the encryption plug in. It provides a nice frontend to creating encryption layers, and does it quite well.

Good luck! Please post success (or other) stories.

Outstanding. Fixed indeed - works like a charm. Thank you!!

Any findings?

Quote from igrnt

Thanks for reporting. So what's your setup, is /dev/md127 a RAID array? What is the partitioning on it like, and which of those partitions are LUKS containers? If you can tell me this, I will attempt to reproduce and work out where the plugin is going haywire.

Pleasure: /dev/md127 is a RAID5 array. It has been partitioned into three partitions (/dev/md127p1..3). In the current test, only p2 is a LUKS container - p1 and p3 are not. (I made this setup to test my own LUKS-on-top-of-OMV setup, before I bumped into your cool plugin; my setup had three partitions, one "plain" and two LUKS containers with different key configurations).

Thank you!

Thanks for making this plugin! This is a great addition to OMV.

I started playing with it on my OMV VM. After creating one encrypted partition, I get what's below - the encrypted partition is listed six times. It kind of works aside of this "cosmetic" issue, but I'm sure that's not the intended behavior

Note my setup is not standard, in that I have partitioned the single RAID5 array, and I use these partitions for different purposes (so different keying). It might (must?) be related to why we're seeing this.

Any insight?

*** EDITED *** to correct a couple of glaring errors - thanks @raisOr for providing feedback!! ***

Quote from raisOr

@doron
I managed to setup an encrypted installation (root and swap encrypted) using the wiki article.
I would be very much interested in setting up an encrypted RAID6 now, can you please post the steps (cmds) to be taken here ?

Sure. Basically, what you need to do is create the RAID array structure you want, and then, before creating a filesystem on it, do the LUKS. Then you go on building a filesystem over the dm-crypt layer. OMV is smart enough to detect it, so that all the higher level tools (File Systems, Shared Folders etc.) will be automagically available.

Special care should be given to the location of the key. The crypto setup happens rather early in the boot sequence; your key needs to be available at that time. Either you type it in (boot sequence stops and prompts you on the primary console, you need it to be available to you), or, if you use a key file, it needs to be available. If it is on the (encrypted?) root fs, that should work (root fs is expected to be mounted at that time, obviously).

Okay, buckle up (this is essentially similar to what's described in "Step 3" of the wiki article

1. Create the RAID structure you want. Simplest is to use the GUI. Raid Management --> Create, like you always do, but you can use md if you prefer. Note the name of the device created - /dev/mdxxx . Wait for the RAID array to become fully initialized.

2. Get a root level command prompt. Build an encrypted block device on top of the array. If you plan to type the key (passphrase) during boot, just do:

cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -y luksFormat /dev/mdxxx

Alternatively, if you plan to use a key file, first create the key file (can do via e.g. dd if=/dev/urandom of=/path/to/keyfile bs=1024 count=4) and place it where early init process can find it(!). Then, do:

cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -y luksFormat /dev/mdxxx /path/to/keyfile 

3. Open the encrypted block device, like so (the name "myraid6" is an example, use your own):

cryptsetup luksOpen /dev/mdxxx myraid6

or, if you used a keyfile, use this syntax:

cryptsetup luksOpen -d /path/to/keyfile /dev/mdxxx myraid6

This step creates a new block device, /dev/mapper/myraid6 . We will now use this device for upper-layer actions.

4. Now we need to create a file system. We can simply do e.g.:

mkfs.ext4 -m 0 /dev/mapper/myraid6

Or, we can go back to the OMV GUI, go to File Systems, and select "Create", making sure we are building the file system on /dev/mapper/myraid6 (and not on /dev/mdxxx).

5. Last thing we need to do is add a line to /etc/crypttab, so that the device is opened upon boot. Best is to use the device's UUID (which remains constant in the face of hardware or OS version changes). Find out the UUID by:

blkid | grep /dev/mdxxx

and copy the UUID into a line you add into /etc/crypttab which, if you want to be prompted for a password, will look something like this:

myraid6 UUID=b90f8cce-a777-4915-a871-3cbc4f87c34a none luks

or if you used a key file, like this:

myraid6 UUID=b90f8cce-a777-4915-a871-3cbc4f87c34a /path/to/keyfile luks

That's all there's to it. Now you should be able to use your new filesystem from the GUI, create shared folders, share over NFS/CIFS/AFS or whatever you want to do with OMV.

I hope I haven't missed anything, please report success or failure...

It is possible; I do it. But it calls for all-manual setup.
Basically, what I did is create a RAID array, then encrypt the entire md (i.e. the RAID block device) using LUKS, rather similar to what's described in the wiki page you quoted, and then create a filesystem on /dev/mapper/mdxxx . If you then put this into /etc/crypttab, you can either type the key manually during boot (what you asked for), or point the crypttab entry to a key location, which will make it auto-mount (and a bit less secure, at least for some attack vectors).
From that point on, OMV will detect the filesystem(s) and you can use it as usual, add shares and do whatever.

If you're interested, I can describe this in more details. It is quite straightforward, but it's a completely manual process.

Quote from ryecoaaron

rm -f /etc/apt/apt.conf.d/99openmediavault-release /etc/apt/apt.conf
apt-get update

Ouch. I did see that other post, but since I saw I don't have that 99openmediavault-release file, I presumed it's not applicable to me. How wrong I was.

This worked like a charm. It's all good now. Thank you and sorry for the dup.

I have a single update pending for libcurl3-gnutls-7.26.0-1. When I try to install from GUI, I get the info dialog open, but stuck at the first line: "Reading package lists...". No progress from there.
Tried to kick it a few times, or reboot. No joy.

When I do "apt-get update" from CLI, it ends with the following. Not sure it's related.

Ign http://packages.omv-extras.org kralizec-vb/main Translation-en
Traceback (most recent call last):
  File "/usr/sbin/omv-mkaptidx", line 55, in <module>
    cache = apt.cache.Cache()
  File "/usr/lib/python3/dist-packages/apt/cache.py", line 102, in __init__
    self.open(progress)
  File "/usr/lib/python3/dist-packages/apt/cache.py", line 145, in open
    self._cache = apt_pkg.Cache(progress)
SystemError: E:The value 'stable' is invalid for APT::Default-Release as such a release is not available in the sources

Quote from "puersardiniae"

I have tried to go through the procedure but when i run the step 4 i get the following error:
"mount option <loop> is unknown, invalid argument"
Can you please give me the right comands you have entered in the system and if there were other preconditions that you have not reported

It might be that your kernel does not have loopback device support... This would be the precondition that I missed (I kind of presumed it, - you must have a nonstandard system build). CONFIG_BLK_DEV_LOOP is the kernel option, if that helps.
You may want to type "losetup -f" and see what you get - if you do have loopback support you will see something like "/dev/loop0" - if you don't, probably some sort of rejection.

As the previous poster said, you obviously need this whole thing only if you're having this problem.

Thanks very much folks!!

It now indeed works in FF, does not in Chrome. I have a vague memory that it did (in Chrome) in the past but I may be off here.
Anyway, thanks for fixing it!