It's not rocket science.

If windows was reimplemented as a capability based microkernel like sel4, it would be far more secure. Run drivers in their own isolated processes. Do interprocess communication between them via capabilities and shared memory. Remove all ambient authority from programs. All the programs a user launches stop automatically inheriting all of that user's permissions.

There's no secret knowledge required to do this. The SeL4 team has written extensive documentation of how they did it. They also opensourced their kernel implementation, with correctness proofs for the whole thing.

The reason windows hasn't done it is the cost. You'd have to rewrite half of the NT kernel and refactor everything else. All existing windows drivers would need to be rewritten. If you forced windows userland use a capability based system, you'd essentially be inventing a new way to write windows programs. You'd need to document that, and write a compatibility layer for legacy programs. And solve some UX problems. It would be terribly inconvenient for everyone. Oh, and some programs would run slower as a result.

They could do it if they wanted to. But microsoft just doesn't care about security as much as they care about performance and compatibility. Linux is the same.

The big irony is that security would be a lot cheaper for microsoft if they designed the NT kernel to be more like sel4. Microsoft has to spend millions on security every year because any tiny bug in the kernel (including in drivers) might result in the whole OS being compromised. In a microkernel, a buggy driver is nowhere near as dangerous.

▲

mike_hearn 18 hours ago | parent [-]

Your knowledge is out of date: Windows has supported capabilities from the start of NT and does run a lot drivers in isolated processes, along with most OS services. It has done for years. It has the most sophisticated IPC framework of any OS (DCOM) which is integrated with the operating system kernel's security frameworks, and used pervasively both internally and by apps. And Microsoft has created a new way to write Windows programs in which apps are expected to advertise the capabilities they need (see WinRT and MSIX). This is also over 15 years old.

macOS does the same but with more developer adoption. Apps don't have the ambient capabilities of the user and must advertise what they need via entitlements embedded in the binaries, or get permission just in time.

Which is all very good, and modern platforms are much more secure than they once were. Yet "capabilities" as a silver bullet are academic overpromises. This article I wrote is more about language/runtime level capabilities but OS capabilities are not much better.

https://blog.plan99.net/why-not-capability-languages-a8e6cbd...

SeL4 isn't secure because of One Weird Trick that others would adopt if only if they could be made to care enough, it's "secure" because it hardly does anything, which is why nobody uses it and why it has no impact on real world computer security.

The hard part of desktop security is not changing the operating system. The hard part is getting app developers to care. Most security features added to operating systems are ignored by developers, which is why Apple forces you to adopt some of them as the price of admission to the app store. If they didn't nobody would use them, as can be seen for apps distributed outside of the app store. The reason is security is a market for lemons. Nobody can see the result of security investments so it's irrational to invest. SeL4 has no solution.

	▲	josephg 16 hours ago \| parent [-]
		> Your knowledge is out of date: Windows has supported capabilities from the start of NT and does run a lot drivers in isolated processes, along with most OS services. Thanks! I quickly googled this point before posting earlier to make sure I was still right. Gemini helpfully told me that yes indeed, drivers in windows run in the kernel's main process. Thanks, AI. > This article I wrote is more about language/runtime level capabilities but OS capabilities are not much better. I think I responded to this article at the time. I still find this article somewhat confusing and unconvincing. For example, you conflate Java's SecurityManager with capability systems, even though it seems more like an permission based access control system. Then you point out many of its weaknesses. To what end? What conclusion about capability systems am I supposed to draw from a criticism of this quite different security model? A capability is not a permission flag. Unlike your example, a good capability system would generally pass all HTTP requests to a given endpoint through a single capability object. You wouldn't need different caps for each HTTP method like SecurityManager apparently requires. It's like file handles. You don't create several different file handles to interact with the same file, one for reading, one for writing and so on. We just open the file once, with whatever options are needed. Then the file descriptor can be passed into any function which needs to access that file. And whatever code receives the file descriptor doesn't know if they're talking to an actual file, or some in-memory object or something else. Just like a virtual object. You also say this: > File descriptors are a kind of capability provided by the kernel, but a rather odd and inflexible kind. They aren’t a great example of object capabilities. Huh? File descriptors are often treated as the canonical example of object capabilities. This comment makes me wonder if we're even talking about the same thing. At the risk of being indelicate, are you sure you know what capabilities are? Can you give a definition of object capabilities which doesn't describe file descriptors? The point about god objects lands. I also agree that trying to retrofit a language like java to make modules unable to share memory is difficult. But many aspects of language design work like this. Consider garbage collectors. Before GC languages existed, I could write the same article talking about the difficulties of hacking a GC into C. But that wouldn't teach me anything about how well a GC would work in a language like Java or Ruby. Anyway, the main advantage of capabilities is the ability to split programs out into sub-modules such that a compromise or bug in one part of the system doesn't lead to the entire system failing. We can argue about whether bringing this into the language runtime is a good idea. But I feel pretty confident that this sort of separation is a good idea at the systems level, helping with security and reliability. We can look at Chrome, SeL4, Erlang and - apparently - windows for examples. Even if they don't all think of this as a capability based problem.