[arch-general] mkinitcpio hook for custom root decryption with systemd boot

[Giancarlo Razzolini]

Em julho 23, 2020 7:09 Riccardo Paolo Bestetti via arch-general escreveu:
> 
> I would like to change my current crypto setup in a way that would require more step to unlock the root than just typing in a passphares. For this reason, sd-encrypt clearly cannot serve my use case.
>

What step would that be? And how it would be secure?

> For this reason, I would like to write a custom hook to mount the root volume. Now, systemd boot doesn't have a concept of runtime hooks. Thus, I need to make a systemd unit that gets pulled in by cryptsetup.target in the place of systemd-cryptsetup at .service. (Basically, I need to replace the whole systemd-cryptsetup-generator and systemd-cryptsetup logic.)
>

It doesn't need to be in place of, you can simply have a unit that runs either before or after systemd-cryptsetup at . Or you can even override systemd-cryptsetup to require your unit.
There are several options.

> However, I really have no idea on how to achieve this. Should I write a custom mkinitcpio hook which completely bypasses sd-crypt/cryptsetup.target and instead starts a different unit with my own decryption logic? Or is there a way to hook into cryptsetup.target and instruct it to pull in my logic instead of systemd-cryptsetup*?
>

If you write a unit file and a script, they can probably be added to the FILES section and that would be it. Main issue is the enabling of the unit, so, for that, you would probably need a custom install hook.

> Of course, the other possibility is to just stop using a systemd boot and instead setting up a busybox early userspace. Then it's just a matter of writing a shell script. However, since I'm already using systemd for everything - from the bootloader to userspace - I don't think it makes much sense to do that.
>

If you use the base hook, you already have busybox on the initramfs.

Regards,
Giancarlo Razzolini
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20200723/5096aff7/attachment.sig>