[arch-general] mkinitcpio hook for custom root decryption with systemd boot
I have root encryption set up on my system and I currently boot with the sd-encrypt and sd-lvm hooks. 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. 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@.service. (Basically, I need to replace the whole systemd-cryptsetup-generator and systemd-cryptsetup logic.) 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*? 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. Any help/guidance/suggestion/criticism is highly appreciated. Riccardo Paolo Bestetti
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@.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@. 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
This is a good example how to uncrypt via tpm https://aur.archlinux.org/packages/mkinitcpio-tpm2-encrypt/ On Thu, 23 Jul 2020, 16:03 Giancarlo Razzolini via arch-general, < arch-general@archlinux.org> wrote:
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@.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@. 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
On Thu, 23 Jul 2020 at 12:09, Riccardo Paolo Bestetti via arch-general
I have root encryption set up on my system and I currently boot with the sd-encrypt and sd-lvm hooks.
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.
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@.service. (Basically, I need to replace the whole systemd-cryptsetup-generator and systemd-cryptsetup logic.)
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*?
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.
Any help/guidance/suggestion/criticism is highly appreciated.
Riccardo Paolo Bestetti
haven't looked more deeply into it, but luks/dm-crypt/cryptsetup can use keys in the kernel keyring. So maybe it would be enough for you to have a service that configures the keyring before the cryptsetup service. https://fossies.org/linux/cryptsetup/docs/Keyring.txt -- damjan
participants (4)
-
Damjan Georgievski
-
Florijan Hamzic
-
Giancarlo Razzolini
-
Riccardo Paolo Bestetti