Open adrelanos opened 4 months ago
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?
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.
well, sure, but if you encrypt /usr/ then I am not sure a "golden image" model really is in focus?
i.e. pick one:
I really don#t see the usecase for supporting the mixture of having golden images, yet encrypting /usr/ with a private host key...
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.
- 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.)
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:
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,
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: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
cryptsetup-reencrypt
.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