3 ms·

> log4j would just send those user provided strings over an IPC channel No it'd have to send the strings and a capability for network access. Which it wouldn't

> log4j would just send those user provided strings over an IPC channel No it'd have to send the strings and a capability for network access. Which it wouldn't have unless you were specifically doing that, so it would be able to make network access.

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

monocasa 5y ago

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.