Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

Personally I'd like to see more runtimes with some concept of capabilities. As a user, I'd like to be able to say "this package cannot make outbound calls" rather than doing so at the program or host grain via layer 3 or layer 7 firewall rules. I think maybe Deno allows this, and I wouldn't be surprised if JVM or .Net did as well.

Failing that, it would be interesting to see this implemented as a linter--low level I/O and HTTP functions are annotated such that callers must have the appropriate capability annotation in order to call them. This wouldn't prevent a nefarious library publisher from making HTTP requests through an FFI or an alternate HTTP library unknown to the linter, but it would prevent attackers from exploiting bugs/misfeatures in libraries as in this log4j case.

View on HN

That’s pretty much what the Security Manager is for, which Java has had since the 1.0 version. However it was rarely applied outside of Java applets, and is scheduled to be removed [0] because it is difficult to apply effectively and doesn’t cover all types of vulnerabilities.

[0] https://openjdk.java.net/jeps/411

> Personally I'd like to see more runtimes with some concept of capabilities. As a user, I'd like to be able to say "this package cannot make outbound calls" rather than doing so at the program or host grain via layer 3 or layer 7 firewall rules. I think maybe Deno allows this, and I wouldn't be surprised if JVM or .Net did as well.

Unfortunately both of these platforms have removed their security controls - the JVM's SecurityManager[0] was deprecated and recent versions of .NET have dropped sandboxing. [0] https://openjdk.java.net/jeps/411

You should do it on the network _anyway_. You want multiple layers because you often find that any given layer was not as robust as you assumed.

This doesn’t work. I often want my app to be able to talk over the network, but I want to restrict my logging library from making network calls. You can’t do this at layer 7 much less layer 3. But firewalls at those layers still obviously serve a purpose, just not this purpose.

Your app shouldn’t be talking to randos injected from the outside. This is trivial.

"webhooks"

Sorry, that's not a good answer. That server needs to be locked down, absolutely, in terms of __what kinds of requests it can originate__ and what is reasonable for that request to carry. Otherwise you can end up participating in a relay attack.

Reply on news.ycombinator.com