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

101–110 of 158 posts

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

#101

Post by Ericson2314 »

loeg wrote: post #67
Ericson2314 wrote: post #50

Earlier quoted context omitted.

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…

I believe FreeBSD has removed support in CURRENT.

Oh no that's a bummer. Well I think it's a smallish patch so easy to redo, but still.

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

#102

Post by kortilla »

Here’s the alternate history where “Network” is passed as an argument to the constructor.

The year 2006 rolls around and centralized logging is becoming pretty cool. Someone requests that log4j add support to logging to a UDP syslog server. The constructor now requires “Network” and now everyone still thinks it’s reasonable.

IMO the elephant in the room is code execution of remotely loaded code. I want to be able to give something access to the network but not be able to execute stuff from network provided sources.

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

#103

Post by Ericson2314 »

Ericson2314 wrote: post #101
loeg wrote: post #67

Earlier quoted context omitted.

I believe FreeBSD has removed support in CURRENT.

Oh no that's a bummer. Well I think it's a smallish patch so easy to redo, but still.

Just https://reviews.freebsd.org/D31923 ?

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

#104

Post by Ericson2314 »

catern wrote: post #88
Ericson2314 wrote: post #49

Earlier quoted context omitted.

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…

WASI could be used without wasm, in theory. So it doesn't have to couple changes on multiple axes together. I agree with the other poster, WASI is the next step for those who like CloudABI and Capsicum, and may really win by being coupled to the browser.

By WASI alone you mean just do something a lot like cloudabi with the home directory emulation baked in?

The idea is the interface, and that is very nice and simple, so sure. But I think the ability to catch on must be in the implementation. I suppose parts of the WASI libc could be reused, but those parts could equally well be taken from the original Musl, right?

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

#105

Post by bo0tzz »

kortilla wrote: post #102

Here’s the alternate history where “Network” is passed as an argument to the constructor. The year 2006 rolls around and centralized logging is becoming pretty cool. Someone requests that log4j add support to logging to a UDP syslog server. The constructor now requires “Network” and now everyone still thinks it’s reasonable. IMO the elephant in the room is code execution of remotely loaded code. I want to be able to…

It's a similar story though, that could be covered by another capability - one to access the Java classloader, or run executables on the filesystem, for example.

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

#106

Post by Ericson2314 »

catern wrote: post #89
Ericson2314 wrote: post #54

Earlier quoted context omitted.

I also rewoke this LKML thread https://lore.kernel.org/kernel-hardening/01e72780-e328-23b5-... a few months back, because my one quibble with CloudABI is its all-singing-all-dancing fork+exec abi. Making an embryonic process, mutating it's state as desired, and then submitting to the scheduler is a much nicer workflow, and more in the spirit of capabilities anyways where "fork = duplicate the whole keyring and then d…

FWIW that's what like what I do in rsyscall https://github.com/catern/rsyscall http://catern.com/rsys21.pdf

Ah glad you wrote up the idea. If I get around to trying to have that same conversation with other kernels, would be good thing to point to!

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

#107

Post by continuational »

I am working on a capability-safe language!

I fully agree with this article, and the great thing about object capabilities is that they are just plain values, and require nothing special from the type system.

This also means that object capabilities aren't "colored" like async/await, monads, or other effect systems.

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

#108

Post by alasdair_ »

No, it wouldn’t have, for the simple reason that no one is willing to go to the extra effort to use a capability-safe language, for the same reason we don’t all code in formally-verified languages - it’s just too much work.

The claim in the article could be “The log4j vulnerability could have been prevented by hiring someone to punch any developer who tries to use JNDI in a logging library in the face” and would be equally valid.

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

#109

Post by tomjakubowski »

kortilla wrote: post #102

Here’s the alternate history where “Network” is passed as an argument to the constructor. The year 2006 rolls around and centralized logging is becoming pretty cool. Someone requests that log4j add support to logging to a UDP syslog server. The constructor now requires “Network” and now everyone still thinks it’s reasonable. IMO the elephant in the room is code execution of remotely loaded code. I want to be able to…

The last few paragraphs of the post address your post's alternate history.

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

#110

Post by [deleted] »

mikewarot wrote: post #83

So close to getting to the actual root issue (ambient authority), but so far away (blaming the programmer, instead of structural deficits in the OS). We need operating systems that don't hand out authority like candy if we're ever going to have the usability and freedom that we used to have in the 1980s with floppy based IBM PCs running MS-DOS. I'm constantly dismayed at the ongoing failure of imagination that accept…

[deleted]
Post reply on HN