Overcook0708 What's the equivalent of verified boot for linux ? Something like Dm-verity for /root + stuff like signed PCR policies/ pcrlock that systemd guys are working on ?
I have been running my own immutable build of Linux Mint since 2013.
Back then I installed the Linux distro, made all software and configuration changes that I wanted, and then converted it all into a single .squashfs image file using "mksquashfs". Then I modified the initrd so it would mount the root as an overlay file system with the squashfs image as lower layer, and a tmpfs as the upper writable layer. Then I installed Grub for booting it all. I booted from a USB key to save SHA256 hashes of the bootsector, all Grub files, the kernel, the initrd and the squashfs image. Everytime I needed to verify no compromise had happened, I just booted from the USB key again and verified all the files on disk. Truly immutable.
Today we have EFI, Secure Boot, and support for UKI images which removes the need for the USB key. Just run "veritysetup format" to create a corresponding .verity file for the squashfs image file. Modify the initrd to mount the squashfs image through dm-verity using "veritysetup open --reboot-on-corruption" to enforce verification. Make sure initrd will refuse to boot if anything goes wrong. Then use "ukify" to pack the kernel and initrd and the boot parameters into a single UKI image, which is a regular EFI boot file.
This is my current setup, verifying the checksums for the EFI boot file is enough to know everything is unmodified and uncompromised, since it in turn will verify the squashfs image is unmodified.
Next step would be to sign the EFI boot file using your own Secure Boot keys, and then put Secure Boot in your BIOS into Setup Mode, and enroll your own signing keys instead of whatever would have been there otherwise. I haven't dared doing this part yet, because the risk of bricking your device is huge. If the OpROM for the graphic chip cannot be loaded, you won't even be able to access BIOS anymore. In theory this is possible, and would provide strong verified boot. It can only be compromised by someone who can access or compromise the BIOS itself, and you can not reasonably defend against someone who can do that. Crucially important, the Secure Boot keys you generate must never touch any disk or media an attacker reasonably can get access to.
Theoretically you can measure the boot too, using a PCR on a TPM to release a value used as part of the disk encryption key derivation for any encrypted disks or partitions you have. You might have sensitive files and app data you want to persist after all, and not lose at every reboot. In theory, this would make it such that if someone were able to replace your OS, eg by having physical access to your device and thus ability to disable or re-enroll Secure Boot, the TPM would refuse to release the value needed to unlock the encrypted data, making it inaccessible. But this does not seem very useful, as the attacker would still learn your disk encryption passphrase, and could just add back the original OS images to access your data with your passphrase. To make this actually secure, the value in the TPM must be permanently destroyed in case the device is booted with a tampered boot process. Google Pixel phones implements this, as enrolling new verified boot keys can only be done after triggering wipe of all data on the Titan chip, permanently destroying the data. I don't know if this is possible to do on regular computers yet.
upstage4186 Mkosi is a toolkit that allows you to create immutable Linux OS installs that contain SecureBoot verified, measured (+ TPM PCR registers) UKI kernel images with dm-verity verified immutable A/B root volumes backed by EROFS (truly immutable).
This should give you a pretty good coverage for a verified immutable atomic Linux install with rollback for safety.
Problem with mkosi is that it is basically rolling your own, like I currently do. There is one big downside with that, and that is that you won't get security updates unless you build a new updated image. We all believe, yeah, we will do that once a month. And then 6-12 months go by without doing it. It is too much effort, unfortunately, so we become lazy. It is not a big issue in my use-case, since I use this setup almost exclusively in an offline setting, where timely security updates are not such important, but knowing after every boot that the system is uncompromised is, as I access different data with different sensitivity level at different boot cycles.
For immutable distributions to become useful to most, they must be run by someone, like Fedora, who builds the images so all you have to do is running the update software to get the new updated image. This would also remove the complication of administrating and protecting your own Secure Boot keys.
However, if someone else than you will do this, there need to be a way to install apps in addition to whatever is bundled in the OS itself. These apps then need to be verified too at every launch. But this should be easy to do using AppImage's and a signature file for them. I don't know Flatpak, but maybe it already is similar.
All the components to make this happen already exists, it is just, no one has done it yet. But since SilverBlue and SecureBlue got released, and immutable distributions actually got popular as a concept, I am hopeful that maybe we are not that far away from this happening.