The Mutable OS

Today, I’d like to talk about Windows.

Wait, before you go, just hear me out: “What if Windows was an immutable OS?”

This idea might seem familiar to you. We actually had this, for some values of ’this’, back in the aughts. We called it DeepFreeze. Of course, it was more about freezing the whole partition, and less of making the OS itself immutable, but it was on the right path. Oh, but I haven’t explained “Immutable”.

What?

Immutable, at least as far as software goes, means to be unchanging. If you have an immutable OS, then the OS is essentially read-only. You can’t make changes, you can’t fiddle with it, and that’s by design. This doesn’t mean you can’t fiddle with it. Projects like Fedora Silverblue and NixOS allow you to fiddle with the OS, just outside of the running context. Changes come in signed and sealed updates to the whole system, not one-off patches. That means when you boot your computer, the OS either works, or it doesn’t. If it doesn’t, then most of these systems will roll back to the last working copy, with no leftover bits or half-upgraded components. That means you have a solid foundation upon which to work on.

In short: The system image is a fixed unit. It is what it is at install/update time. When it comes time to patch, you just replace it, wholesale. If that fails for whatever reason, the change doesn’t take place and you’re back to where you were: Working.

We even do this already in the wild with applications. Flatpak, while I disagree with it being a replacement for good package management, does this for applications. Microsoft has it’s MSIX apps from the Windows Store and Apple’s built-in apps are all contained on special partitions that get updated wholesale.

A Brief History

Culture around Operating Systems has evolved over the ~60 years of computing. In the early days, MS-DOS was just some files on the disk that if you deleted or modified would kill your system and require an expensive call to a tech. Later, we organized those files and told people to stay out, but this was mostly convention and not a hard and fast rule. OSes of the Unix variety did have permissions to stop tampering, but these were pretty rudimentary and easy to mess up.

As OSes have matured as the state of the industry has seen more harmful actors willing data destruction or theft on users and organizations, we’ve put up more roadblocks. Windows has mostly kept apace with this by erecting stronger permission models and adding things like UAC and sandboxing with MSIX. Not all of this is well received, but it’s the state of the system. However, a lot of the problems that I, as a desktop support tech, see could probably be mitigated by making the OS layer read-only.

Why?

When your OS is read-only. You, nor Bob, or Sally or xXx420BlazeItBigBallsxXx can make changes to the system. That’s it. No more weird OS errors, trojans, unbootable systems, half installed patches or corrupt system files. Your computer turns on, and verifies the system is the way it’s supposed to be and you go on your merry way. This allows folks like me and my security “friends” to worry about your data more, and less about tweaking knobs so that you can’t install 30 toolbars, delete system32.dll or get some drive-by-malware infection from a advertisement.

The patching story cannot be undersold. When “Patch Tuesday” rolls around, you don’t have to worry about it not finishing and leaving you in a half-working state, or not applying some of the patches because of an improper order or some weird lock on a file not being removed. The whole thing is replaced. If that replacement doesn’t work, then you just reboot (probably being done anyway) and you’re back to the last known good state.

This is being done already on macOS and lowers the effective surface area for attacks to take root, and makes sure when you turn on your computer, it actually turns on and boots up. The same system can also be used to ensure that applications follow the same behavior. Installing Microsoft Office like this would ensure that when you open Word, Word is what you get. Just like the OS, no more half-installed configurations, broken components and reinstall/repair cycles to fix that toolbar button.

How?

Well, that’s the billion-dollar question. There is some groundwork done for this already. There is virtualization and container support in Windows and we already have a lot of prior art in Faronics’ DeepFreeze software. The big missing area, at least as I can see it is backwards-compatibility and handling overrides or configurations.

The story doesn’t end with monoliths like Microsoft, Apple or Red Hat handing off blessed OS images and you’re just forced to accept it. You can configure things, make changes, and deploy images that are blessed. This even allows you to layer configurations atop a blessed image to further customize it. Keeping the OS layer pristine, the configurations in their own space and the user system all separate, but perceptually unified components that don’t fight with each other.

Backwards compatibility is going to be a non-starter. Too much software written by companies expect to read and write into C:\Windows, C:\Program Files or even C:\ itself. Preventing that will break those programs. Honestly, though? That’s a small sacrifice in my eyes. These programs were already broken to begin with. Insufficient defense around the ability to read/write to protected OS areas is bush-league and should need to be rewritten anyway. It’s 2025.

We Already Have Immutable OSes at Home

You’re already running them. iOS is immutable, Android is containerizing things and already employs this with Work and Personal containers for apps and data. ChromeOS is completely immutable, verified boot, separate user data partition, the works. Even macOS has begun locking down things by making the OS a signed partition that requires booting into the recovery partition to make changes. Linux is one of the leaders in this space due in no small part to them being used in servers, where containerization is the mechanism du jour for deploying applications and virtual infrastructure and services. There are even desktop systems built on Linux that bring the immutability to the masses.

Since the whole industry is enjoying the benefits of reliable platforms, the question becomes: “Why isn’t Microsoft?”

Well, they are. Kind of. The problem is that Microsoft being Microsoft tries to cater to Microsoft. That means “Windows S Mode” requires you to get your apps from the Windows Store and use Edge. I mean, they get points for trying. However, if most of the top search results for “Microsoft Windows S Mode” are for disabling it, then we have a problem. People like their apps, and the Windows Store doesn’t have most of them. Despite Microsoft’s on-again-off-again commitment to encouraging developers to embrace things like the store, it’s just not happening.

Could it be Done?

Yes. But also: probably not. Microsoft doesn’t like change, except when they do. Their golden cow is backwards compatibility, and killing that, even for a subset of terrible applications, is going to be met with fierce resistance. Any perceived change in the current system will likely upset the whole ecosystem and push people to other platforms.

I’m sure that Microsoft knows this. Which is why we still have the leaky SS Windows being used in literal trillion-dollar companies with unbelievably tight security requirements, despite it not being immutable. There is so much momentum to just keep on using it that it’d take a seismic shift in industry thinking to even broach the subject realistically.

Wrapping up

I don’t really hate Windows. I may not like the company behind it, but the engineers’ blood-sweat-and-tears is proof enough that some very smart people have built something that endures – despite it’s array of comically low-hanging fruit problems.

I think we’ve outgrown the model of mutable systems, especially in high-security environments. When I find myself recommending iPads over laptops, it’s not because I’m an Apple shill. It’s because the platform is reliable, and I don’t get calls about some patch or security product wrecking performance. The platform itself obviates the need for so much of the resource-hungry observation and remediation that’s become the status quo.

Implementing immutability isn’t about locking people out. It’s about providing a verifiable system that ensures stability and security by defining clear boundaries and enforcing them. When you turn your computer on – like a TV – it should just work. We already have this in phones, ChromeBooks and even macOS.

This isn’t a radical idea. In an age of rampant credential theft, ransomware and cryptomining zombie farms, maybe the real question is:

Why are we running so much of that on a platform that isn’t immutable?

Comments

A comment from Hacker News pointed out that Windows even includes a DeepFreeze-like feature called UFW, which can redirect disk writes to memory or the paging area. So, what is the hold up from Microsoft? It seems like they could implement immutability posture in chunks by removing the ability for programs to write to areas they shouldn’t by overlaying UFW in key areas.

Respond via email.