search

aplanas / dracut-pcr-signature

Dracut module to import PCR signatures
GNU General Public License v2.0
1 stars 3 forks source link

[Tumbleweed] unbootable system with dracut-pcr-signatures #2

Closed TobiPeterG closed 7 months ago

TobiPeterG commented 7 months ago

I tried to add measured boot to Tumbleweed, but the system is now unbootable with the module included as the https://github.com/aplanas/dracut-pcr-signature/blob/main/pcr-signature.sh script fails when running systemd-cryptsetup@cr_root.service. The service has been replaced by a link to that script. The script fails as the command "mktemp" isn't available in my initrm stage. I could workaround this by deleting the service override (this made the system bootable again) and then I deactivated the module.

Can this behaviour be replicated?

aplanas commented 7 months ago

Can you try this? https://build.opensuse.org/package/show/home:aplanas:branches:devel:microos/dracut-pcr-signature

TobiPeterG commented 7 months ago

New error (since it's initrd stage, this was the easiest way to get the error message; should a log be required, I'll save the complete log): IMG20240412220611

aplanas commented 7 months ago

seems that there are missing modules for FAT32, like nls_cp437 or nls_iso8859-, but they are explicitly included in module (https://github.com/aplanas/dracut-pcr-signature/blob/main/module-setup.sh#L16C31-L16C54)

Can you see it in the generated initrd? (you can use lsinitrd for example)

TobiPeterG commented 7 months ago

Well, now I got the issue on my second machine as well lol

I can provide the whole initrd if wanted. The output of lsinitrd: https://pastebin.com/iW1XTPzu

I see

-rw-r--r--   1 root     root         3426 Mar 18 09:18 usr/lib/modules/6.8.6-lqx2-3-liquorix/kernel/fs/nls/nls_cp437.ko.zst
-rw-r--r--   1 root     root         3066 Mar 18 09:18 usr/lib/modules/6.8.6-lqx2-3-liquorix/kernel/fs/nls/nls_iso8859-1.ko.zst

On this system, I haven't even tried to setup pcr prediction, I just use sdbootutil for systemd-boot. :(

aplanas commented 7 months ago

OK, lets try to debug this.

Can you check if you have strace installed? If not install it (you can remove it later)

In the initrd shell, mount the rootfs can copy the strace from it into the initrd. Maybe you need to copy also some of the libraries.

mkdir /tmp/mnt
# Change it with the ESP device
strace mount -o ro /dev/sdaX /tmp/mnt

At some point will complain. You can redirect the output into the rootfs for later sharing.

TobiPeterG commented 7 months ago

OK, lets try to debug this.

Can you check if you have strace installed? If not install it (you can remove it later)

In the initrd shell, mount the rootfs can copy the strace from it into the initrd. Maybe you need to copy also some of the libraries.

mkdir /tmp/mnt
# Change it with the ESP device
strace mount -o ro /dev/sdaX /tmp/mnt

At some point will complain. You can redirect the output into the rootfs for later sharing.

Sure, will do this tomorrow. :)

Two general questions: A) why does this tool override the cryptsetup service? It would be nice if this tool could fail and the system still boots. Also, isn't the cryptsetup service response for asking for the password? What Instance e.g. asks for a password should the predictions not match? B) why is this tool needed? Can't systemd-cryptenroll be used to enroll a public key and a signed file? Doesn't systemd handle including these files in the initrd?

aplanas commented 7 months ago

I am still not able to reproduce the issue, btw.

Two general questions: A) why does this tool override the cryptsetup service?

The script needs to be executed just before the cryptsetup service, but after the device is registered.

It would be nice if this tool could fail and the system still boots.

I changed the script a bit to do not fail during the mount (https://github.com/aplanas/dracut-pcr-signature/commit/ae07fc611de1884207614125533482477e9e2f8b)

Also, isn't the cryptsetup service response for asking for the password? What Instance e.g. asks for a password should the predictions not match?

B) why is this tool needed? Can't systemd-cryptenroll be used to enroll a public key and a signed file? Doesn't systemd handle including these files in the initrd?

This service is the one that copy the predictions from the ESP into the initrd in RAM. If the prediction match no password will be asked. I cannot update initrd and include the predictions, because this will change the measured initrd (and make the included perdition automatically invalid)

The alternative to this service is to improve the systemd-credentials to work with type#1 boot entries.

Vogtinator commented 7 months ago

As mount already prints, dmesg should provide more info.

TobiPeterG commented 6 months ago

I am still not able to reproduce the issue, btw.

Two general questions: A) why does this tool override the cryptsetup service?

The script needs to be executed just before the cryptsetup service, but after the device is registered.

It would be nice if this tool could fail and the system still boots.

I changed the script a bit to do not fail during the mount (ae07fc6)

Also, isn't the cryptsetup service response for asking for the password? What Instance e.g. asks for a password should the predictions not match?

B) why is this tool needed? Can't systemd-cryptenroll be used to enroll a public key and a signed file? Doesn't systemd handle including these files in the initrd?

This service is the one that copy the predictions from the ESP into the initrd in RAM. If the prediction match no password will be asked. I cannot update initrd and include the predictions, because this will change the measured initrd (and make the included perdition automatically invalid)

The alternative to this service is to improve the systemd-credentials to work with type#1 boot entries.

Updated, now I can boot my system again with dracut-pcr-signature :) Now we just need to find out why I can't mount any efi partitions lol I'll try to capture a dmesg later :)

One question though: when I understand it correctly, the expected PCR values are in the json on the efi partiton together with the initrd/kernel. What prevents an attacker to manipulate the kernel/initd and replace the pcr hashes in the json file?

TobiPeterG commented 6 months ago

dmesg shows this: IMG20240420135806

Could this lead to the errors?

aplanas commented 6 months ago

One question though: when I understand it correctly, the expected PCR values are in the json on the efi partiton together with the initrd/kernel.

Mostly. The pcr-oracle json file contains the signed policy, that can be build only with the correct PCR values. Technically is not the PCR values, but a hash derived from the policy (that depends on those PCR values).

For pcrlock the json file contains (among other things) an index on the non volatile ram inside the TPM2 of your machine. This is like a register that contains the policy hash.

What prevents an attacker to manipulate the kernel/initd and replace the pcr hashes in the json file?

Right. If the hacker changes the initrd with one with a backdoor, they need to change the json file. In the pcr-oracle they need to know the private they used to sing it (that it is stored in the encrypted part of the system). To improve the security the pcrlock stores the policy inside the TPM2, and for change that they need to know the secret PIN, that is encrypted also by the same active policy.

TobiPeterG commented 6 months ago

One question though: when I understand it correctly, the expected PCR values are in the json on the efi partiton together with the initrd/kernel.

Mostly. The pcr-oracle json file contains the signed policy, that can be build only with the correct PCR values. Technically is not the PCR values, but a hash derived from the policy (that depends on those PCR values).

For pcrlock the json file contains (among other things) an index on the non volatile ram inside the TPM2 of your machine. This is like a register that contains the policy hash.

What prevents an attacker to manipulate the kernel/initd and replace the pcr hashes in the json file?

Right. If the hacker changes the initrd with one with a backdoor, they need to change the json file. In the pcr-oracle they need to know the private they used to sing it (that it is stored in the encrypted part of the system). To improve the security the pcrlock stores the policy inside the TPM2, and for change that they need to know the secret PIN, that is encrypted also by the same active policy.

Ah that makes sense, thank you very much :)

TobiPeterG commented 6 months ago

OK, lets try to debug this.

Can you check if you have strace installed? If not install it (you can remove it later)

In the initrd shell, mount the rootfs can copy the strace from it into the initrd. Maybe you need to copy also some of the libraries.

mkdir /tmp/mnt
# Change it with the ESP device
strace mount -o ro /dev/sdaX /tmp/mnt

At some point will complain. You can redirect the output into the rootfs for later sharing.

I had some time to test it, here's the strace log: https://pastebin.com/jb4LC1zL

I hope this provides some hints why the mount call fails :)

Vogtinator commented 6 months ago

Please provide dmesg, that will most likely contain the more detailed error.

TobiPeterG commented 6 months ago

Please provide dmesg, that will most likely contain the more detailed error.

The complete dmesg https://pastebin.com/05fT15zu

As already said above and shown in the screenshot, it only inlcudes the utf-8 error

Vogtinator commented 6 months ago

It says that UTF-8 shouldn't be used for vfat due to case sensitivity issues. I doubt it will cause any issues in practice, but it's probably something YaST should avoid.