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

91–100 of 158 posts

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

#91

Post by mikewarot »

catern wrote: post #87
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…

Operating systems are also written by programmers. An operating system written in a capability-safe language would not have such ambient authority problems.

If that were true, you could cross compile Windows 10 to Rust Source code (or whatever language you think its magic enough to be safe), compile it from that language, and then it would never have a security problem again.

Obviously that's not true.

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

#92

Post by justinpombrio »

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…

> 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).

Indeed, this is the entire point of the post! (Well, the second point of the post. The "deeper issue".)

- The root cause is ambient authority: the fact that log4j (and its further dependencies like JNDI) can just create a network connection without having been explicitly given the ability to do so.

- This is not the fault of the programmer. I was focusing blame on the programming language not having capabilities, though as many commenters including you have pointed out, capabilities at the OS level are also very important. Ultimately you want both, and they complement each other.

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

#93

Post by catern »

mikewarot wrote: post #91
catern wrote: post #87

Earlier quoted context omitted.

Operating systems are also written by programmers. An operating system written in a capability-safe language would not have such ambient authority problems.

If that were true, you could cross compile Windows 10 to Rust Source code (or whatever language you think its magic enough to be safe), compile it from that language, and then it would never have a security problem again. Obviously that's not true.

Cross-compiling OpenSSL to Rust and then compiling the Rust would also not get rid of the memory-unsafety vulnerabilities created by writing OpenSSL in C.

Nevertheless, if you wrote OpenSSL in Rust, or any memory-safe language, it would not have those memory-unsafety vulnerabilities.

The same applies when writing in a capability-safe language. It's fairly deliberately ignorant to call these kind of properties "magic".

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

#94

Post by adrianN »

mikewarot wrote: post #91
catern wrote: post #87

Earlier quoted context omitted.

Operating systems are also written by programmers. An operating system written in a capability-safe language would not have such ambient authority problems.

If that were true, you could cross compile Windows 10 to Rust Source code (or whatever language you think its magic enough to be safe), compile it from that language, and then it would never have a security problem again. Obviously that's not true.

That's not true because the compiler of the magical safe language would likely reject the Windows 10 source and "cross compiling" is actually a major rewrite.

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

#95

Post by junon »

adrianN wrote: post #94
mikewarot wrote: post #91

Earlier quoted context omitted.

If that were true, you could cross compile Windows 10 to Rust Source code (or whatever language you think its magic enough to be safe), compile it from that language, and then it would never have a security problem again. Obviously that's not true.

That's not true because the compiler of the magical safe language would likely reject the Windows 10 source and "cross compiling" is actually a major rewrite.

No, it's mostly not true because Rust does not prevent logic bugs.

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

#96

Post by adrianN »

junon wrote: post #95
adrianN wrote: post #94

Earlier quoted context omitted.

That's not true because the compiler of the magical safe language would likely reject the Windows 10 source and "cross compiling" is actually a major rewrite.

No, it's mostly not true because Rust does not prevent logic bugs.

Which is why I explicitly didn't write "Rust" is my comment.

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

#97

Post by chii »

justinpombrio wrote: post #92
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…

> 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). Indeed, this is the entire point of the post! (Well, the second point of the post. The "deeper issue".) - The root cause is ambient authority: the fact that log4j (and its further dependencies like JNDI) can just create a network connection without having been explici…

> the fact that log4j (and its further dependencies like JNDI) can just create a network connection without having been explicitly given the ability to do so.

i dont think this is the responsibility of log4j to express it's capabilities like that. The responsibility should be in the runtime - like the JVM, or even the OS.

Services should run in a sandbox, like how a browser runs a webpage in a sandbox, and only allow capabilities explicitly being requested, and require a human to allow it. Or, have a sandbox such that no matter what code executes, it cannot do more harm than a pre-determined amount (such as limited disk space, limited CPU usage, network usage etc).

The root cause is the security model of modern applications.

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

#98

Post by naasking »

teitoklien wrote: post #69

What you need is not a capability safe language, but rather a tool to make application jails and similar systems more accessible. Your os exists for a reason, let it handle the sandboxing for you, and not the language. Otherwise you fall into troubles later with different sandboxing vulnerabilities in different compilers. Have a codebase that compiles using deprecated features which are removed on language version 2.…

Sandboxing cannot provide the same security benefits of capabilities, even in principle.

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

#99

Post by naasking »

alerighi wrote: post #36
jayd16 wrote: post #9

Earlier quoted context omitted.

It might be useful that some code in a single process have access while other parts do not. How would you propose an OS handle those cases?

And how do you do that, without operating system support? I mean, you can't of course limit that based on the code, in the JVM there is only a single address space, thus every method or class can be instantiated from anywhere in the code (despite public/private/etc. that are only for programmer convenience, they are easily circumvented with reflection, they don't provide any security at all). You can imagine doing so…

> I mean, you can't of course limit that based on the code, in the JVM there is only a single address space

You can in principle, just look at the Joe-E language.

The article is likely talking about revisions to existing VM designs though, because capabilities are a fundamental, architectural decision that underlie the runtime.

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

#100

Post by klodolph »

chii wrote: post #97
justinpombrio wrote: post #92

Earlier quoted context omitted.

> 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). Indeed, this is the entire point of the post! (Well, the second point of the post. The "deeper issue".) - The root cause is ambient authority: the fact that log4j (and its further dependencies like JNDI) can just create a network connection without having been explici…

> the fact that log4j (and its further dependencies like JNDI) can just create a network connection without having been explicitly given the ability to do so. i dont think this is the responsibility of log4j to express it's capabilities like that. The responsibility should be in the runtime - like the JVM, or even the OS. Services should run in a sandbox, like how a browser runs a webpage in a sandbox, and only allow…

Running a whole service in a sandbox doesn't offer the kind of granularity you might want.
Post reply on HN