First, you don’t have full control of your system. Your system is running an unknown amount of code as binary firmware blobs even if you’re using a completely open source kernel. Hopefully you’re compiling every package yourself and not using pre-compiled binaries from your distribution’s repositories.

Second, immutable distros are primarily a distribution and update mechanism that vastly improves the current model of running X number of package updates and scriplets on every machine and hoping it works. There’s nothing that stops you from remounting a filesystem as rw at least on any of the distributions that I know of. There’s also plently of stateful, rw holes for data and configuration on “immutable” distros.

I like the traditional package system, I don't like containerising everything (though I know that is not necessarily coupled with immutable distros). Because then every package can have different library versions and the dynamic loader can't do its thing.

But it's more the configuration that I want to be able to adjust, or to recompile things. As a typical example, on alpine I always need to recompile sudo as their standard version doesn't allow PAM which I need. On an immutable system such tools would usually be in the immutable part.

I had problems with macOS when they switched to immutable (and if you turn off the protection it turns off a whole load of other things too). If I as much as changed the /etc/ssh/sshd_config it would revert with updates.

And really the traditional package system works totally fine for me.

I think you're taking the term "immutable" too literally.

Immutable does not mean you cannot change it according to your wishes. It just means that each change must be explicitly declared in order to be included in the next system image.

In some ways, having a declarative, immutable distribution makes the process even easier, as is the case with NixOS. If you want to patch your sudo, it would be as easy as doing

security.sudo.package = { pkgs.sudo.overrideAttrs (old: { patches = [ (fetchPatch {url = "<url>"; sha256 = "<patch sha256sum>"})];})};

And then you're done.

100% truth be told, having a declarative, immutable distro has allowed me to experiment and configure my system way more than I would have otherwise. I mean, I can do anything because I have the safety net of rolling back if I mess up.

Furthermore, being declarative means I know exactly how I got to my end solution, instead of having to memorize a bunch of steps from different attempts that may or may not have been successful.

Declarative is very different from immutable. They're two separate concepts.

See Apple's implementation where the OS files are protected by signatures and the system won't boot if they're changed. Immutable does mean you can't change it, though I'm some cases you can enable and disable some parts. Nix is declarative and perhaps not immutable. It's advised not to mess with config files but you still can if you wish, it's just a bad idea because it'll be overwritten.

I'm not really against declarative management though I'd consider it something more appropriate for servers where I don't want to change stuff on the fly. On my workstation I don't want to do a complete change time every time I want to modify something. I also don't want to learn the complex syntax so I've never really dived into nix.

I like FreeBSD's compromise of having most configuration in one file but still a traditional system.

He's talking about the management of his system, not the development of his system.

I don't see how you are giving up any control. Look at how to make a custom ublue distro. It's basically just a docker build that results in an image. But you can do anything you want before that image is finalized.

>it's only really making one step in the kill chain harder, which is establishing persistence

Yep. An attacker can just surreptitiously add a line to your .bashrc instead of modifying the base OS.

Indeed, though it won't give them root persistence but yes. It's a bit harder to weed out when it's hidden somewhere in the OS but it's not a serious protection IMO, even if file signatures are validated on every boot like Apple does.

But they also use this to enforce DRM, for example if you turn off system integrity protection you can't run iOS apps anymore. This is exactly the kind of thing that bothers me about it.

> Indeed, though it won't give them root persistence but yes.

If you gain root by editing .bashrc and replacing sudo or placing a file in .local/share/applications to replace an application that the user trusts (like the Settings app) to give their password to, then you can just inject your payload into the initramfs and get persistence.

I don't believe any desktop distro is signing and verifying the initramfs.

Yeah I know, there's always options to get persistence.

And yeah the problem is that the initramfs is built on the machine itself. So it would have to have the signing keys which defeats the purpose.

Apple does sign the entire boot process but they have the benefit of a strictly defined hardware set to support.

> Apple does sign the entire boot process but they have the benefit of a strictly defined hardware set to support

Windows can also sign the entire boot process, but they unlike Apple can't make the system folders read-only due to backwards compatability (Windows 10S experimented with this idea but was scrapped).

There's nothing stopping Linux distros from having a secure boot process, but the initramfs either has to be scrapped or pre-built by the distro.

>And yeah the problem is that the initramfs is built on the machine itself. So it would have to have the signing keys which defeats the purpose.

Just brainstorming here.

What if the initramfs was rebuilt every time the OS was upgraded. During an OS upgrade, the user is asked to cold boot, the machine does a special boot, requests the user's disk decryption password, and uses it to build and sign the new initramfs, based on files signed by distro maintainers.

Then for every ordinary boot, immediately after disk decryption, we keep the disk decryption password in memory for just a little bit longer, and use it to check the signature on the initramfs before continuing with the boot.

The "signature" could be the secure hash of [the disk decryption password concatenated with the initramfs binary], or something (ask a crypto expert -- perhaps KDF+HMAC is better?)

I'm guessing the disk decryption password is much harder to steal than the user's root password?

(I might be totally out to lunch here, I know nothing about Linux boot. The above comment is written in the spirit of "learning about things by asking dumb questions"!)

* What if the initramfs was rebuilt every time the OS was upgraded.*

On most distributions, they already are if the kernel changes in anyway. This is what ends up filling up your /boot partition.

Then for every ordinary boot, immediately after disk decryption, we keep the disk decryption password in memory for just a little bit longer, and use it to check the signature on the initramfs before continuing with the boot.

You can just reuse the existing architecture of secure boot/tpm to store public keys (although GRUB is a disaster and will likely break your boot chain of trust). You normally can't add additional keys unless the system is in setup mode. But, the process to add a self signed key is not user friendly and you'd still need to store the private key on disk to sign additional images, which malware can access.

There is a process to generate something known as a UKI, where it can be a signed kernel/initramfs verified by the firmware secure boot, but I believe only Red Hat has keys to sign anything and most distos get given a signed shim that will only boot the turd called GRUB.

If you aren't already doing private cicd, effectively acting as "the OS developer", you don't have "full control" over your system.