4 ms·

Excuse us true believers, but the idea is capabilities avoid the https://xkcd.com/2044/ https://xkcd.com/2044/ trap by being just dynamic enough. I would certa

Excuse us true believers, but the idea is capabilities avoid the https://xkcd.com/2044/ 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.

monocasa 5y ago
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.
- justinpombrio 5y ago
  > 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.

monocasa 5y ago

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.

justinpombrio 5y ago
> 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.