option to set up full disk encryption during first boot

[adrelanos]

Component

systemd-cryptsetup

Is your feature request related to a problem? Please describe

I am a Linux distribution maintainer.

As already mentioned in #32714, citing again here. In Fitting Everything Together you mentioned:

Live Systems vs. Installer Systems vs. Installed Systems

In my model I'd like to remove the distinction between these three concepts as much as possible: each of these three images should carry the exact same /usr/ file system, and should be suitable to be replicated the same way.

So I want to provide a generic image for users to download. The image should be able to be flashed on an internal hard drive, a USB drive, on a server or anywhere else.

So do I provide,

• A) an unencrypted image; or
• B) an encrypted image; or
• C) both?

Some users will want to use unencrypted images and have use cases for that. Others will want to use full disk encryption.

How is that solved nowadays? Linux distributions are providing a live/installer images, and the installer will ask the user if they want to use encryption or not.

It would be good if the extra complexity of installers having different source code for setting up such complex things would be no longer required.

Shipping an image encrypted with a default, public, well known key and then telling the user to change the password and using cryptsetup-reencrypt also seems not like the best solution. That makes it more difficult to mount the image for unencrypted use cases. In #29824 @bluca asked:

Why not just encrypt on first boot, instead of shipping it already encrypted?

True. The only issue is, that this is a complicated sysadmin task. All documentation I could find on the topic requires booting from an external disk and running multiple complicated commands. Something which most users won't be able to do.

Describe the solution you'd like

The user having the option to encrypt the operating system at first boot.

It does not need to be limited to first boot. Full disk encryption could be set up during any subsequent boot.

This feature would probably need to be run from inside the initial ramdisk prior mounting of the root disk.

If this feature request sounds good overall, the question is how to implement an interface for this. Perhaps a special key combination and/or kernel parameter that can be set to enter the program which will handle enrollment of the key such as prompting for the password and set up of the encryption.

Describe alternatives you've considered

• In-place encryption: After first boot, the user could perform in-place encryption. That does not really exist on the Linux platform.
• Providing two different images from download. An unencrypted one and an alternative one that is encrypted with a default key which the user needs to change after first boot + cryptsetup-reencrypt.
• Keep using Live Systems with Installers that handle unencrypted vs encrypted by asking the user during the installer.
• Ship an encrypted image and use systemd to enroll a new LUKS full disk encryption key and perform cryptsetup-reencrypt at first boot.

OpenSUSE can encrypt during first boot but ideally this work would be upstreamed to systemd if appropriate.

https://news.opensuse.org/2023/12/20/systemd-fde/

https://en.opensuse.org/Systemd-fde

The systemd version you checked that didn't have the feature you are asking for

No response

[poettering]

Our general recommendation is to ship /usr/ with dm-verity and then format/encrypt the root fs on first boot. Why doesn't that work for you?

That means no reencryption, and everything is protected the way it should be protected?

[adrelanos]

Full disk encryption including /usr/ is a frequent feature request and preferable for better privacy. It's such much wanted feature, Calamares and other Linux distribution installers spent a lot effort to implement that. Even mkosi supports it.

[poettering]

well, sure, but if you encrypt /usr/ then I am not sure a "golden image" model really is in focus?

i.e. pick one:

1. golden images that encrypt rootfs on first boot
   OR
2. encrypt /usr/ too, with a local installer...

I really don#t see the usecase for supporting the mixture of having golden images, yet encrypting /usr/ with a private host key...

[adrelanos]

My main point is to get rid of Live Systems vs. Installer Systems vs. Installed Systems differences as much as possible. An installer would be no longer needed (or be highly simplified) if the installation of a Linux distribution can become as simple as flashing a "golden image" to an (internal) hard drive.

The installer should not need to chroot the image, run scripts there, etc. As it is now, Calamares installer has complex code for setting up bootloader, initrd, partitioning, file systems, encryption and much more. This seems all avoidable.

• Bootloader? initrd: mkosi handling that.
• Partitioning, file systems? systemd-repart handling that.
• Encryption? Not handled by systemd project yet. Hence, this feature request.

2. encrypt /usr/ too, with a local installer...

Best if local installers and their complex, hard to maintain, develop code can be avoided?

systemd project idea of mkosi-initrd to avoid specialized scripts in the initrd is nice. Let the regular maintainer of the upstream project handle it. No dracut modules or alike needed. That simplifies a lot.

Linux installers are similar to an initrd from a code complexity perspective. They also have modules that have different code, which is not maintained by the upstream packages. (Calamares setting up the partitioning isn't handled by systemd-repart etc.)