SDB Talk:Encrypted root file system
Should be polished (the layout and title)?
If you want to contribute, please read the rules for this wiki and if you have any questions, don't hesitate to contact the wiki team, we are more then willing to help you! :-)
There seems to be interest to have http://old-en.opensuse.org/Encrypted_Root_File_System also in the 'new' wiki: http://lists.opensuse.org/opensuse-de/2010-10/msg00009.html . So I did the import. But I doubt that this is the 'right' namespace (maybe [[SDB:]] ?) or the article is fitting to the new-wiki's beauty-guidelines. And according to so mailing-list someone wants to make some changes to actualize the article? Regards --Pistazienfresser 10:24, 1 October 2010 (MDT)
Links from openFATE
- There is a link from "openFATE #305633: Support installation with encrypted root file system" to Encrypted Root File System with SUSE HOWTO. Is this article or its predecessor meant? --Pistazienfresser 10:11, 4 October 2010 (MDT)
Statements to be executed as root AND sudo
It says: Please execute the commands and edit the files listed below as root.
And after that each and every statement shown is prefixed by "sudo".
I know usage of sudo spreads like a disease, but this is really double.
Stuck on swap disk at boot
After applying .root.key to not only my root partition, but also my (encrypted) swap and home partitions and rebooting, the boot got stuck waiting for the swap disk. It turned out that my swap had been set to passno 0 in /etc/fstab, while the root partition had passno 1. IIUC, this resulted in a kind of deadlock: root won't be mounted before swap comes up, and swap can't be unlocked without access to the root disk (where crypttab is).
I'm not sure if that passno 0 was my own doing, or something that happened by default, so I'm not sure if it's relevant to add to the main page. Still, it may be useful to someone, so... putting it here.
Oh, and the solution was to boot in recovery mode and change the swap's passno to 2. I also ran mkinitrd; not sure if that was necessary or not. Snild (talk) 08:30, 2 April 2022 (UTC)
Not sure if I was just lucky before (that is, my "fix" wasn't really a fix) or if my `zypper dup` earlier this week broke something, but... the problem came back. This time, I fixed it by removing the "resume=" kernel cmdline arg from /etc/default/grub. Snild (talk) 14:20, 10 April 2022 (UTC)
Boot with single password entry - an alternative with TPM2.0 on Leap 15.4
./root.key may be compromised rather quickly, e.g., by means of an unencrypted backup. It is possible to get rid of the ./root.key by means of TPM2.0.
Tested on Leap 15.4 on Qemu/KVM with Tiano Core, Secure Boot, TPM2 CRB emulation. systemd-cryptenroll for TPM2 is also a working solution on a hardware TPM, cf. https://bugzilla.opensuse.org/show_bug.cgi?id=1194433
Pre-requisite: you have converted the luks1 partition to luks2. Then, for encrypted LVM on /dev/vdXY perform the following:
zypper install tpm2.0-toolssystemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/vdXYChange 4th column of /etc/crypttab on the correspoding cr_vdXY to "tpm2-device=auto", then
dracut -fNow, waiting for GRUB TPM support in Leap for this to become as user-friendly as some other big OS.
Why 700 permissions on /boot/ ? (breaks libguestfs)
Why are 700 permissions needed for /boot/ to protect the initrd?
As far as I can see dracut creates the initrd with 600 permissions as /var/tmp/dracut.*/initramfs.img and cp's it then to /boot/. So the /boot/initrd-* should be already well protected at all times. No need to set 700 for the whole /boot/ directory.
Can someone explain? Maybe I missed something.
Unfortunately a /boot/ directory with permissions 700 breaks libguestfs. Running libguestfs-test-tool as ordinary user will fail because it can't read /boot/vmlinuz-*.
UPDATE 2023-12-13
Frank Kunz originally wrote that section.
https://en.opensuse.org/index.php?title=SDB:Encrypted_root_file_system&diff=prev&oldid=125948
And he agrees that it can be removed.
So I'll remove that /boot permissions section it in the next days if nobody objects.
On 2023-12-13, 20:17 Frank Kunz wrote:
> [...]
> On 2023-12-13, 12:24 Duge wrote:
>> Hi Frank,
>>
>> can you help me to understand why
>> chmod -R g-rwx o-rwx /boot
>> is needed when /boot/initrd-* contains a LUKS keyfile?
>> https://en.opensuse.org/SDB:Encrypted_root_file_system#In_Leap_and_Tumbleweed
>
> That is now some time ago, but as far as I remember the earlier
> versions of mkinitrd/dracut did not set the access rights for the
> created initrd images to 0600 root:root only. In the meantime that
> changed so that the initrd is only readable for root, and therefore it
> is safe to remove that part from the description.
> [...]
Duge at pre-sense de (talk) 09:35, 18 December 2023 (UTC)
UPDATE 2024-01-03
Removed /etc/permissions.local for /boot/ section:
https://en.opensuse.org/index.php?title=SDB%3AEncrypted_root_file_system&type=revision&diff=183157&oldid=182917
Duge at pre-sense de (talk) 09:51, 3 January 2024 (UTC)