> Let's not conflate network access to get the thing from LDAP and network access for the thing itself.
Why not? The attacker's goal was to run untrusted code on your server. They don't necessarily care if it's running in the JNDI process or the server component that's logging as the first step. It's a beachhead into a pretty trusted component, and exploits these days are long chains. I'm sure there are other components over those IPC channels that aren't expecting JNDI to be lying now which can be used to expand that beachhead.
> as no one would design the JNDI interface to wantonly pass all the same capabilities to the class.
Just as 'no one' would load random class files off of untrusted servers into a vm without the fine grained capabilities you're talking about?
> Well-sandboxed arbitrary byte-code is remote code execution I am OK with!
I agree with the spirit, but haven't found a sandbox that stayed "well-sandboxed" over time.
Excuse us true believers, but the idea is capabilities avoid the https://xkcd.com/2044/ trap by being just dynamic enough.
I would certainly agree not to trust any other sort of sandboxing. E.g. I don't trust Linux namespaces (as the linux devs themselve say you shouldn't) because the syscall interface is far too complex and subtle). But something like CloudABI or Fuschia or seL4 is dramatically narrower in scope.
I'm talking from experience here with capability systems on microkernels. Capability-based security is a tool, not a panacea. Exploit chains these days are very used to having to jump through IPC channels to components with different privileges to get everything they need.
Edit: As an aside, rather than looking towards namespaces for an attempt at the same structure, seccomp BPF is the primitive I've found that creates the closest thing to the capability system you're talking about. That way you can leave a process with only recvmsg/sendmsg on unix domain sockets, and maybe mmap for memfds shared across processes.
> Exploit chains these days are very used to having to jump through IPC channels to components with different privileges to get everything they need.
Thank you for bringing this up; it's an important point. Do you have a sense of what a practical solution might be?
One thing I can imagine is that there's a JNDI component, but to communicate with it over IPC, you need the JNDIComponent capability. This would allow a couple ways to prevent the log4j vulnerability:
1. You don't give the JNDIComponent to log4j.
2. You use capabilities inside JNDI to separate out the bits that use the network from those that don't, and only supply log4j with a JNDIComponentWithoutNetworkAccess.
This requires co-operation between capabilities in the OS and in the programming language, though, which is a big ask. Plus some foresight; much more than as described in my post.
Why not? The attacker's goal was to run untrusted code on your server. They don't necessarily care if it's running in the JNDI process or the server component that's logging as the first step. It's a beachhead into a pretty trusted component, and exploits these days are long chains. I'm sure there are other components over those IPC channels that aren't expecting JNDI to be lying now which can be used to expand that beachhead.
> as no one would design the JNDI interface to wantonly pass all the same capabilities to the class.
Just as 'no one' would load random class files off of untrusted servers into a vm without the fine grained capabilities you're talking about?
> Well-sandboxed arbitrary byte-code is remote code execution I am OK with!
I agree with the spirit, but haven't found a sandbox that stayed "well-sandboxed" over time.