FS#47282 - [mkinitcpio] add support for unlocking truecrypt partitions + containers
Attached to Project:
Arch Linux
Opened by blitmap (blitmap) - Sunday, 06 December 2015, 15:08 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 18 June 2016, 18:24 GMT
Opened by blitmap (blitmap) - Sunday, 06 December 2015, 15:08 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 18 June 2016, 18:24 GMT
|
Details
Description:
cryptsetup supports unlocking truecrypt volumes now, even file containers. Please add support for unlocking a truecrypt volume from the kernel cmdline, which would then prompt the user for a password like your average LUKS volume. This would involve making slight changes to the 'encrypt' hook at: /usr/lib/initcpio/hooks/encrypt I had this working about a month ago before I had to wipe my setup for other reasons. I had Linux within a truecrypt container on my Windows partition. I made a separate hook to mount the Windows partition pre-boot, then had the `encrypt` hook unlock the truecrypt file container from a path I specified in the kernel cmdline, then it continued as normal - `root` was set to the unlocked volume id of the container. root=/dev/disk/by-partlabel/etc... Supporting truecrypt disks/partitions is easy. Supporting truecrypt file containers is slightly harder, we need another hook for mounting volumes pre-boot. (crypttab without encryption) Anyway, I'm installing Arch again right now. My very minor modifications were heinous but I'll post it when I'm done. I'm hoping an actual Arch dev can do it cleaner/better. |
This task depends upon
Closed by Dave Reisner (falconindy)
Saturday, 18 June 2016, 18:24 GMT
Reason for closing: None
Additional comments about closing: There's no clear bug here. The feature is supposed to be supported. Upstream would know more.
Saturday, 18 June 2016, 18:24 GMT
Reason for closing: None
Additional comments about closing: There's no clear bug here. The feature is supposed to be supported. Upstream would know more.
In the long-run I think we should be using the systemd-related hooks. Right now I see a lack of support in Arch's existing `encrypt` hook.
I need 2 things:
1) `encrypt` should support unlocking Truecrypt drives/partitions to use as the `root` on the kernel cmdline
2) We need another hook for mounting partitions so a Truecrypt file container can be made available to then unlock. think: mount=/dev/disk/by-label/...:/mounted/path/ cryptdevice=truecrypt=/mounted/path/container.tc root=/dev/disk/by-partlabel/etc..
Something to that effect?
If this setup can be described by /etc/fstab and /etc/crypttab, then it's workable. There's currently support in the sd-encrypt hook for /etc/cryptttab.initramfs, which we'd need to mirror for fstab.
There's little interest in extending the non-systemd hooks.
https://wiki.archlinux.org/index.php/Mkinitcpio#Common_hooks
Anyway, this is a feature proposal. If you're saying there's little interest in making the pre-systemd hooks better, then oh well. I will try to share what I did to `encrypt` once I reinstall, but I am looking for someone to do it nicer/cleaner.
I am fairly sure the sd-encrypt hook, using crypttab, doesn't support unlocking file containers off of other partitions that must be pre-mounted, though.
I learned that this issue is not specific to mkinitcpio, as the encrypt hook/script is installed with the `cryptsetup` package.
After this I tried to recreate my boot setup with the sd-encrypt hook.
I am not actually sure if sd-encrypt allows for unlocking the root device from an entry in /etc/crypttab - it did not work for me.
Either sd-encrypt doesn't support unlocking the *root device* - or sd-encrypt doesn't support unlocking regular files (truecrypt file containers). I think it could be failing because the path specified is not a block device - the `encrypt` hook uses a function from init_functions called "poll_device()" to test if the device exists. I think sd-encrypt or systemd might be doing something similar - and it's failing because I am never prompted to unlock the root device that I specified in /etc/crypttab.
I'm going to work on creating a diff from how I modified the existing `encrypt` hook (not sd-encrypt) and I'll publish that here soon :>
I then changed my kernel cmdline to this: root=/dev/mapper/<LABEL>
Still no dice. I don't even get prompted to unlock the drive, it just skips ahead saying it can't find the root device.
In crypttab.initramfs the line looks like this:
<LABEL> /windows/Users/<USER>/Desktop/container.tc - tcrypt
Am I still doing something incorrectly here?
PS: I know for a certainty this path is valid, I have the modified non-systemd encrypt hook using it.