Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A capability-safe language would have minimized the Log4j vulnerability

justinpombrio.net

Post reply on HN
Print view View original

41–50 of 158 posts

Re: A capability-safe language would have minimized the Log4j vulnerability

#41

Post by fiddlerwoaroof »

DarkmSparks wrote: post #21

Personally I wonder whether anyone actually used log4j willingly or just because its generally used by all the apache projects and they wont start without it. With a healthy dose of "use the latest versions" mentality. I checked back and all my java code was still running log4j 1.1, and removing it has been on the todo list ever since it needed linking. You should be checking all your 3rd party source code, "capabili…

I think you’re misunderstanding capabilities: they can apply also at the class/method/module level. If you’re language doesn’t have “ambient authority”, nothing can create a network connection unless it’s explicitly granted permission to do so and, typically, this permission is granted by passing some sort of non-forgeable token around.

Re: A capability-safe language would have minimized the Log4j vulnerability

#42

Post by ryukafalz »

Ericson2314 wrote: post #40

Capabilities are underrated as a generally way to purge bad archictures, make it clearer what code is doing, and generally cut accidental complexity & improve programmer productivity. This is a big deal, because many security practices are neutral or bad for programmer productivity. We need a big project to get CloudABI implemented in all the major kernels to make the theory reality. Whereas before it was unclear wha…

Agreed re: the general idea, but isn't CloudABI in particular superseded somewhat by WASI? Its repo seems to say it is: https://github.com/NuxiNL/cloudabi

(WASI is similarly capability-based, as I understand it!)

Re: A capability-safe language would have minimized the Log4j vulnerability

#43

Post by tialaramex »

the_arun wrote: post #10

Ideally all egress network connections should go via NAT Gateway & filters at NAT Gateway should have policies to say which request can go out. Failures do happen in programming, we need to have better guardrails ensuring security.

NAT is completely orthogonal to this problem. You say people could have network filters, they could, with or without NAT.

Re: A capability-safe language would have minimized the Log4j vulnerability

#44

Post by monocasa »

ryukafalz wrote: post #35
monocasa wrote: post #25

Earlier quoted context omitted.

Practically (and like is being suggested here in other comments), JNDI would probably be a separate component (maybe a separate process) with network access, and log4j would just send those user provided strings over an IPC channel, and you'd be in exactly the same place at the end of the day.

Sure, it could be, but in a capability system if the application is starting that JNDI component, granting it network access, and granting the logger access to it: 1) It's pretty dang explicit to the programmer that they're granting the logger network access, because they're the ones writing that logic. 2) Even if you've granted the logger network access, you probably haven't granted it complete access to your filesy…

What it would probably look like was they were granting an IPC channel to the JNDI component, just like they would for DNS or what have you. And then separately "ok, yeah, JNDI needs network access, that makes sense".

So you wouldn't see network access directly in the capability manifest for the logging component.

None of this protects you from "fuck it, load class file from random ldap server" that was apparently coded up in JNDI.

Re: A capability-safe language would have minimized the Log4j vulnerability

#45

Post by pjmlp »

Ericson2314 wrote: post #40

Capabilities are underrated as a generally way to purge bad archictures, make it clearer what code is doing, and generally cut accidental complexity & improve programmer productivity. This is a big deal, because many security practices are neutral or bad for programmer productivity. We need a big project to get CloudABI implemented in all the major kernels to make the theory reality. Whereas before it was unclear wha…

> As of October 2020, CloudABI has been deprecated in favor of WebAssembly System Interface for lack of interest

On its Wikipedia entry, so most likely it won't go anywhere.

Re: A capability-safe language would have minimized the Log4j vulnerability

#46

Post by avar »

MattPalmer1086 wrote: post #30
vsareto wrote: post #6

Why should a programming language be limiting network access? Why wouldn't we do this via the operating system?

That would be difficult to do within an application. If your app needs network access, but logging performed by the app should not, how could the OS help there?

The usual ways to do that are to open a connection to the things you need at startup, and then drop your privileges, set ulimits or whatever. Or you don't have network access at all, but pipe your logs to a local process that does.

Alternatively the application can be made to have some OS-specific rules to e.g. generate iptables rules on Linux, so it can contacts its logger, but not anything else.

All of those are probably anathema to the typical Java programmer though, as they require crossing the boundary from JVM into OS configuration.

Re: A capability-safe language would have minimized the Log4j vulnerability

#47

Post by pjmlp »

to11mtm wrote: post #16

So, IDK what the Java world had that was similar, but in .NET at one time they tried to solve this at the runtime VM level with the concept of Security Permissions and trust levels. In practice, this wound up being: - Somewhere between too confusing/frustrating to developers (especially ASP.NET ones, where often the escape hatch of 'AllowPartiallyTrustedCallersAttribute' would get thrown around) - Hard to manage from…

Java had JAAS, which fulfilled a similar purpose, and it is scheduled for removal for similar reasons CAS was taken out of .NET.

Re: A capability-safe language would have minimized the Log4j vulnerability

#48

Post by nickdothutton »

randombits0 wrote: post #39

What you let out is just as important as what you let in.

For at least 25 years we have been telling people to implement egress filtering and to only allow outbound the specific, known, necessary connections from any given server. Rarely do I see it done.

Re: A capability-safe language would have minimized the Log4j vulnerability

#49

Post by Ericson2314 »

ryukafalz wrote: post #42
Ericson2314 wrote: post #40

Capabilities are underrated as a generally way to purge bad archictures, make it clearer what code is doing, and generally cut accidental complexity & improve programmer productivity. This is a big deal, because many security practices are neutral or bad for programmer productivity. We need a big project to get CloudABI implemented in all the major kernels to make the theory reality. Whereas before it was unclear wha…

Agreed re: the general idea, but isn't CloudABI in particular superseded somewhat by WASI? Its repo seems to say it is: https://github.com/NuxiNL/cloudabi (WASI is similarly capability-based, as I understand it!)

I don't think so. WASM is changing things on many fronts. CloudABI is just doing one front.

I don't have any thing against WASI, and I don't blame them for wanting to point out a like-minded project that was still active. But just as I think CloudABI is a good stepping stone for seL4 or Fuschia, I think it is a good stepping stone for WASM.

Also, I guess I don't believe in coupling change on in principle independent axes. If you at least allow the knobs to be turned separately, even if you don't e.g. CI or otherwise support all combinations, you are incentivized to handle things more "parametrically" vs if-def soup (which matches capabilities, incidentally!) and you have a great way to troubleshoot stuff. This is like how NetBSD says they like supporting obscure architectures to catch more bugs in the portable code too, not just make their lives harder.

Re: A capability-safe language would have minimized the Log4j vulnerability

#50

Post by Ericson2314 »

pjmlp wrote: post #45
Ericson2314 wrote: post #40

Capabilities are underrated as a generally way to purge bad archictures, make it clearer what code is doing, and generally cut accidental complexity & improve programmer productivity. This is a big deal, because many security practices are neutral or bad for programmer productivity. We need a big project to get CloudABI implemented in all the major kernels to make the theory reality. Whereas before it was unclear wha…

> As of October 2020, CloudABI has been deprecated in favor of WebAssembly System Interface for lack of interest On its Wikipedia entry, so most likely it won't go anywhere.

I know, but support is still in FreeBSD. My big long term plan is:

1. Work on FreeBSD cross in Nixpkgs, because I need a way to pin forks and run nice VM tests without going insane. (We already have NetBSD cross.)

2. Rig up a booting image that uses https://github.com/InitWare/InitWare, the fork of systemd.

3. Add support to CloudABI in initware.

4. Bang on drum for other OSes and upstream systemd to implement this stuff we can can good portable abstractions -- I think this is our best shot to get "portable containers".

Post reply on HN