A capability-safe language would have minimized the Log4j vulnerability

I think it's reasonable to describe one as more coarse gained when it simply doesn't have enough information to be as precise as the other method. Yes, they work at the same layer and can do vaguely the same things, but s targeting makes a huge difference.

As was said with the .Net had something like this.

This reminds me of Threads vs Tasks in .Net also, where to do async threading well, you used to have use API's that wanted the kitchen sink of options.

To one group of user this was a chance to go read lots of stuff and workout what all these options meant and why they where want, security etc etc. Writting solid code, etc etc.

To the other group of users, you get a magic screen full of code you cut'n'paste and it "magically works", this bit done, next problem.

Then Tasks came alone, and the code Demo's well because it just works and is sleek and only needs "a couple of lines of code". That is until you want to use a pool, and manage this and that, and slowly you learn/add all layers that provide the old API's functionality, as you discover you actually needed more code.

Which relates, the log4j code "just worked" so everyone closed that issue, and got another ticket started. There is mostly not idea of craftmanship, it mostly "velocity" based thinking. Thus in the last decade the simpler snippets of code that just work, allow more cheaper/mindless monkeys. And we just grab packages, tools , and leverage "free and awesome" but don't understand anything of what is actually happening.

And it's not going to improve, because there is a drive for more code, code is already too expensive, so it's just going to be done cheaper and cheaper. So whatever neat "solutions" to the "nobody will ever read the manual to do it correctly" problems of this class represent, they better work, for all the ever increasing people, that will never read the manual.

Because the programming language knows things at a finger-grained level than the operating system does, which can allow for better protection.

WASI could be used without wasm, in theory. So it doesn't have to couple changes on multiple axes together.

I agree with the other poster, WASI is the next step for those who like CloudABI and Capsicum, and may really win by being coupled to the browser.

It's JNDI, a network library namespace library sort of like DNS but using LDAP.

Going off what I've seen for DNS daemons in capability systems, the whole point is to not have a network capability on the client of the daemon at all, but only in the DNS daemon, who gets IPC channels setup by by some minter of capabilities in the TCB. That IPC layer lets you make JNDI requests, but because of the capability model is a non forgeable permission over the idea of DNS lookups both of the local cache and over the network if need be. The the DNS daemon is the only one with a network capability for a random UDP port to make requests.

So what you have in your fine grained caps is

    DNS daemon
      * IPC server port
      * UDP port

    client app
      * client port to DNS daemon

If someone coded that DNS daemon as 'you know what, new DNS record type called CAFEBABE that is an arbitrary, untrusted server name and path to load some untrusted .class file from', both the above capability system implementation wouldn't help, and we'd take the DNS daemon authors out and flog them for implementing that. If it was in the RFC we'd take the writers out and flog them too. That's the best defense I've found unfortunately.

And the big issue is that there's tons of these caps even now needed for a system, and it's hard to manage it all even when explicitly in a big table. At best it sort of looks like Terraform, at worst it looks like JCL or an autotools script. It's real easy for it to expand out of someone devops person's mental scope, where we all take potshots on the Internet for not following some hardening guide instead of other guides on a breach.