| View previous topic :: View next topic |
| Author |
Message |
nick_0189
n00b
Joined: 28 Jul 2022
Posts: 13
|
 Posted: Fri Jan 31, 2025 12:43 am Post subject: Dracut /etc/crypttab Support in Initramfs |
 |
|
Hello everyone,
In summary: Generally, when will Dracut use a crypttab file in the initramfs?
I'm trying to understand the documentation for Dracut and how I should configure it for my installation. Specifically, I don't understand the relationship between `/etc/crypttab` and Dracut. Dracut includes an option for parsing a crypttab file (`man dracut.cmdline`, `rd.luks.crypttab`), but crypttab seems to really be more of a systemd thing and I can't get Dracut to unlock root with a crypttab file embedded in the initramfs at `/etc/crypttab` - a custom module or cmdline arguments are required to unlock it. Does it unlocking root from information in a crypttab file work for anyone else? How much support does Dracut actually have for a crypttab file, since it is mentioned only briefly in the documentation and in the code?
In the source code here it looks like Dracut parses a crypttab file when the `rd.hostonly` option is passed, but why does it seem like it actually doesn't support a crypttab file the way I think it does?
I can't find anything specifically stating that Dracut doesn't support a crypttab file, and I can't find anything specifically outlining the extent to which Dracut supports a crypttab file. It's confusing to me. Any clarification would be helpful.
Thank you. |
|
| Back to top |
|
 |
sMueggli
Guru
Joined: 03 Sep 2022
Posts: 538
|
| Posted: Fri Jan 31, 2025 5:06 pm Post subject: |
|
|
| Generally Dracut does not need/read the /etc/crypttab. But that is only "generally" the case. |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 2004
|
| Posted: Fri Jan 31, 2025 5:23 pm Post subject: |
|
|
In the general sense, cryptroot-ask.sh is triggered by the bootup process via a udev rule and it will read crypttab if it exists.
However, it only reads it for your defined name of the device mapper location (e.g. /dev/mapper/gentoo-crypt) once the device has already been scheduled to open.
All the devices to query and open are done via one of the rd.luks command options. |
|
| Back to top |
|
|
nick_0189
n00b
Joined: 28 Jul 2022
Posts: 13
|
| Posted: Sat Feb 01, 2025 5:52 am Post subject: Dracut Initramfs: Crypttab and Udev Behavior |
|
|
Hi grknight,
Thank you for your response. So Dracut only uses crypttab to open volumes specified with a `rd.luks` cmdline option? So if I wanted to open two disks `cryptdisk1` and `cryptdisk2`, I would need to add the following to my configuration at `/etc/dracut.conf.d/luks.conf`:
| Code: | install_items+=" /crypto_keyfile.bin /crypto_header /etc/crypttab "
kernel_cmdline+=" rd.luks=cryptdisk1 rd.luks=cryptdisk2 root=/dev/mapper/cryptdisk1 " |
And then to `/etc/crypttab`:
| Code: | # Volume Name Encrypted Device Key File Options
cryptdisk1 /dev/sda /crypto_keyfile.bin header=/crypto_header
cryptdisk2 /dev/sdb /crypto_keyfile.bin |
I tried this configuration, but it did not work because it failed to find root. Should I expect it to work with an option for a header?
Also, I see that Dracut contains udev rules in `95udev-rules`, which installs a series of udev rules. One of these rules is `60-persistent-storage.rules`, which sets up links in `/dev/disk/by-id`. The `initqueue/finished` hook is run when udev has settled, but if I install a module to the `initqueue/finished` hook, why can it not read disks in `/dev/disk/by-id/`? A check is required first like the following to force Dracut to try the module again later: | Code: | if ! { test -b /dev/disk/by-id/xxx-0xXXXXXXXXXXXXXXXX; }; then
exit 1;
fi |
Shouldn't this module not be run until udev has settled, or is this not what is meant by udev being "settled?" |
|
| Back to top |
|
|
sMueggli
Guru
Joined: 03 Sep 2022
Posts: 538
|
| Posted: Sat Feb 01, 2025 10:05 am Post subject: |
|
|
Let's assume you have two LUKS containers. One of them contains your system (FDE, no unencrypted /boot) and the other contains sensitive work stuff. Having a kind of FDE with an unencrypted /boot makes the life easier for Grub, but not for the kernel or Dracut.
When your system boots it needs to unlock the system and mount it to /. The firmware (UEFI nowadays) loads the bootloader from the (unencrypted) ESP (or from the hard disk in case of BIOS boot mode).
The bootloader needs to load kernel and initramfs. Because /boot resides inside a LUKS container Grub needs to unlock the container (no need for /etc/crypttab), read and execute the /boot/grub/grub.cfg and load the kernel and initramfs.
The loaded kernel needs to mount the system to /. Because the system resides inside a LUKS container the kernel needs to unlock the system first with the help of an initramfs, but again, the crypttab is not needed. If that happened the kernel can start and do other stuff like mounting the second LUKS container.
The job of Dracut is to generate a "useful" initramfs (being able to unlock a LUKS container and mount it and provide kernel modules and firmware).
The LUKS container with the system does not need to be part of the crypttab (my FDE does not even have a crypttab). And crypttab is read later, after the "Dracut magic" happened.
Please note that it is not good practice to use the same LUKS key for several LUKS containers. If you only want one key, you should also put everything into the same LUKS container. If you have several LUKS container, you should also use different keys.
And because you are adding the LUKS key to the initramfs you need to have an encrypted /boot. Otherwise you do not need encryption because everyone (including attackers) can unlock your container with the help of the LUKS key in the unencrypted initramfs. |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 2004
|
| Posted: Sat Feb 01, 2025 1:29 pm Post subject: |
|
|
| nick_0189 wrote: | | Thank you for your response. So Dracut only uses crypttab to open volumes specified with a `rd.luks` cmdline option? So if I wanted to open two disks `cryptdisk1` and `cryptdisk2`, |
Actually, it only uses rd.luks.partuuid, rd.luks.uuid, or rd.luks.serial options if specified manually (and only one of them). If none of those are specified, then it falls back on its own detection based on rd.auto setting. crypttab is not used for detection |
|
| Back to top |
|
|
nick_0189
n00b
Joined: 28 Jul 2022
Posts: 13
|
| Posted: Sat Feb 01, 2025 5:56 pm Post subject: |
|
|
Hello grknight, sMueggli,
Thank you all for your responses.
| Quote: | | Actually, it only uses rd.luks.partuuid, rd.luks.uuid, or rd.luks.serial options if specified manually (and only one of them). If none of those are specified, then it falls back on its own detection based on rd.auto setting. crypttab is not used for detection |
So Dracut doesn't use the crypttab file in any case? If so, why then is it referenced in the source? Or are you saying that the crypttab will be referenced when unlocking a single device listed from the `rd.luks.{partuuid,uuid,serieal}` cmdline option? Could it be that it is only pulled in by the `rd.crypttab` option for use by specific systemd modules? I've been trying to figure out why it's referenced in the documentation but doesn't appear to have any real use case. It's confusing when trying to unlock certain devices before root can be mounted because unlocking a list of encrypted devices is normally what a crypttab file is for, right? It seems like the only way to get multiple encrypted devices unlocked or unlocking an encrypted device with additional options beyond just a keyfile is through a custom module though.
| Quote: | | Please note that it is not good practice to use the same LUKS key for several LUKS containers. If you only want one key, you should also put everything into the same LUKS container. If you have several LUKS container, you should also use different keys. |
Why does this apply in this specific scenario? The keys would always have to be located on the same system either on the boot partition or in root for this to work, and both of those devices are encrypted. If a hypothetical attacker gained access to one key, the attacker would have equal access to the second key. One key, two keys, same access, same security, they might as well be the same key from an accessibility perspective. Are you saying the key for the boot partition should reside on the root device and the key for the root device reside on the boot partition and just refrain from mounting the boot partition after booting the main system except for kernel upgrades?
Also, when do the `/dev/disk/by-id` links become available in Dracut? I have a module in the `initqueue/finished` hook and it does not detect them at first even though `initqueue/finished` is only supposed to run after udev has settled. Does this question belong in a separate topic?
Thank you for your help. |
|
| Back to top |
|
|
zen_desu
Tux's lil' helper
Joined: 25 Oct 2024
Posts: 116
|
| Posted: Sat Feb 01, 2025 8:09 pm Post subject: |
|
|
What is your goal here? Do you need to unlock multiple LUKS volumes which are somehow assembled to provide access to the real root?
_________________
µgRD dev
Wiki writer |
|
| Back to top |
|
|
nick_0189
n00b
Joined: 28 Jul 2022
Posts: 13
|
| Posted: Sat Feb 01, 2025 10:28 pm Post subject: |
|
|
Hi zen_desu,
My question is purely academic. The question is what does Dracut use a crypttab file for, and if it doesn't use it then why does the documentation make references to it?
I am editing some personal notes because I think it would be cool to put them on a public website or add them to wiki pages. In a page covering a Gentoo Installation, I note that to unlock a volume with non-default options such as the --header or --plain options a custom module is needed, but I don't actually know why that is the case since Dracut allegedly supports adding a crypttab file to the initramfs.
An example setup that might use something like this: | Code: | Device Mapper Mountpoint
/dev/sda /dev/mapper/cryptroot /
/dev/sdb
/dev/sdb1 /efi
/dev/sdb2 /dev/mapper/boot /boot |
Drauct is able to mount this unless cryptroot has other settings required to open it, such as a --header or --plain even though valid crypttab files might have these options included.
Then my second question about udev is similar. My computer has two disks which are identical models and sizes. Depending on the setup, they might not have partition tables and therefore no UUIDs. Generally, they will initialize in the same order, but to be sure I think it is better to reference them using /dev/disk/by-id/ instead of only the device files in /dev/. The /dev/disk/by-id/ directory doesn't seem to be ready though until some time after the initqueue/finished hook is run, so a check is needed at the beginning of a module to make sure that these files have been created before running the hook. I am confused by the documentation though because udev is supposed to be settled before the initqueue/finished hooks are run. I think I am misunderstanding what "settled" means in the context of udev.
Does that make everything clear? |
|
| Back to top |
|
|
zen_desu
Tux's lil' helper
Joined: 25 Oct 2024
Posts: 116
|
| Posted: Sat Feb 01, 2025 11:51 pm Post subject: |
|
|
I was under the impression dracut used the crypttab if you have hostonly mode enabled and don't specify luks cmdline options.
_________________
µgRD dev
Wiki writer |
|
| Back to top |
|
|
nick_0189
n00b
Joined: 28 Jul 2022
Posts: 13
|
| Posted: Sun Feb 02, 2025 12:52 am Post subject: |
|
|
I tried to use Dracut to install an initramfs with a crypttab file but it will not unlock the root partition.
`/etc/dracut.conf.d/luks.conf`
| Code: |
install_items+=" \
/boot/crypto_keyfile.bin \
/boot/crypto_header \
/etc/crypttab \
"
kernel_cmdline+=" \
quiet \
rd.hostonly \
rd.crypttab \
rd.fstab \
rd.debug \
root=/dev/mapper/cryptroot \
"
|
`/etc/crypttab`
| Code: |
# Volume Name Encrypted Device Key File Options
cryptroot /dev/sda /boot/crypto_keyfile.bin header=/boot/crypto_header
boot /dev/sdb2 /boot/crypto_keyfile.bin
|
To generate the initramfs:
| Code: |
doas dracut --kver 6.6.62-gentoo-dist --force -H
|
I can also upload the `rdsosreport.txt` file if that would help, but is the above configuration meant to work according to Dracut's documentation? |
|
| Back to top |
|
|
sMueggli
Guru
Joined: 03 Sep 2022
Posts: 538
|
| Posted: Sun Feb 02, 2025 9:10 am Post subject: |
|
|
| nick_0189 wrote: | | Quote: | | Please note that it is not good practice to use the same LUKS key for several LUKS containers. If you only want one key, you should also put everything into the same LUKS container. If you have several LUKS container, you should also use different keys. |
Why does this apply in this specific scenario? The keys would always have to be located on the same system either on the boot partition or in root for this to work, and both of those devices are encrypted. If a hypothetical attacker gained access to one key, the attacker would have equal access to the second key. One key, two keys, same access, same security, they might as well be the same key from an accessibility perspective. |
If you think that attackers can only get the key, if they have access to the file(s), then you are right. But there are also other attack vectors. |
|
| Back to top |
|
|
nick_0189
n00b
Joined: 28 Jul 2022
Posts: 13
|
| Posted: Mon Feb 03, 2025 3:30 am Post subject: |
|
|
| Quote: | | If you think that attackers can only get the key, if they have access to the file(s), then you are right. But there are also other attack vectors. |
Maybe. You'd have to elaborate on these other attack vectors though because I am not familiar with them.
But I am really more interested in how Dracut handles crypttab files, if anybody could help with that. As far as I can tell, Dracut doesn't use a crypttab file, but it is still referred to in the documentation. This is confusing to me. If anybody knows what I am misunderstanding, please do leave a note here. The udev question is also still open. Why does it appear that the initqueue/finished hook run before udev has settled?
Please let me know if there is any clarification I can provide or if there is a better way I should word these questions. Thank you. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Installing Gentoo
