I agree with your points about the Unix threat model being designed around protecting users from each other, but for completeness I'd like to point out that while modern Linux/BSD systems ship with Discretionary Access Control (DAC) by default, SELinux implements a Mandatory Access Control (MAC) system which is much more fine grained. SELinux is not limited to the traditional Unix security model.

Short simplified example highlighting DAC/MAC differences: DAC asks "is user Alice allowed to read Bob's files?" while MAC asks "is the SMTP server (subject user/role) process allowed to read private keys (object type) of the HTTP server (object user/role)?"

And if you're really motivated (read: want to have fun diagnosing unexpected file permission issues), you can associate files and processes with different security categories and levels (MCS/MLS), implementing horizontal and vertical separation. For example, "is this software update service allowed to read confidential files owned by the accounting database or keys used to encrypt classified information?"

There are other MAC systems besides SELinux as well.

The point of the article is that actually using a fine-grained MAC model is inconsistent with the way we actually use our tools.

It requires deep understand of both the application and the model, which requires a lot of work.

Is Windows much better with its VMS legacy kernel? It has a complex permission model with ACLs and everything but that trades inadequate permissions for something like the SELinux problem. There are too many knobs. (For this discussion leave aside the backward compatibility baggage which is another issue.)

The only approach that I see as viable without rebuilding the entire compute universe is VMs, either the web browser (JS and WASM sandboxes) approach or the qubes type approach.

"We have an isolation problem. Let's use a VM!"

Congratulations, you have just introduced an L1TF attack surface, and the bad guys are now freely reading all physical memory.

You have traded an absolutely enormous attack surface of hundreds of syscalls and a whole system full of files and apps for a much narrower attack surface involving the CPU and whatever the hypervisor exposes which can just be virtio-style pseudo-devices. Besides if the CPU is vulnerable than regular apps can probably exploit it too.

Also I didn't say the best approach would necessarily be hardware VMs, though that is one option and is valuable to let you just plug and play existing applications unmodified. I personally think we need to get away from shipping all software as raw hardware-tied binaries in favor of something like WASM. Java and the .NET CLR had the right idea decades ago, but these were insufficiently versatile and too tied to just one language or platform instead of being a general purpose VM bytecode. WASM is heading in the right direction but doesn't seem to quite be there yet.

Only apps that actually need to use e.g. special CPU features or run tightly optimized ASM code should ship with native binaries or native modules/libraries for the high-performance parts, and that should be something you have to approve.

I hear a lot of, "Let's solve isolation with VMs," without taking into consideration that if you put two fully-patched kernels side-by-side, very few people (i.e., only those sitting on 0-days) have any idea how to exploit the workload running directly on the fully-patched kernel, while everyone knows how to exploit the (Intel) host when they have root/CAP_SYS_ADMIN in the VM and the host has HT enabled.

VMs are far from magic security sauce, and especially if you need HT on Intel hosts, you actively want to avoid using VMs as a "security boundary." You're far better off with the attack surface of a fully-patched OS image from a reputable vendor.

The problem I see with wasm as the sole basis for a secure app platform is that then a web browser can't be just another app on that platform, unless the performance of the browser's JS engine is hobbled or perhaps wasm gets some kind of JIT compilation support. So maybe the web browser engine needs to be the platform, as in Chromium OS, although even Chromium OS has now compromised that original purity with support for Android and desktop Linux VMs.

Using VMs like this means the VM itself becomes hard-core security-critical but if apps have stupid bugs their damage is quite limited.

It also means you can mitigate things like Spectre or RowHammer by just tweaking how the VM JIT compiles bytecode into machine code. You don't have to update apps or even the kernel per se (though the latter would be a good idea).

I agree with you, but if we look past the hack of dynamically creating new users per process, isn’t the security model “sufficient”? E.g. I believe android’s security is quite elegant with the different user per-process model, communicating only through IPC and with heavy use of SELinux (which is much more useful in this model).