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

141–150 of 158 posts

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

#141

Post by kragen »

mikewarot wrote: post #118
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.

Please let me re-state my objection to your assertion, in a different, and hopefully more constructive, manner. An Operating System is a program that multiplexes hardware resources and makes them safely usable by a number of applications. If the design of that system is flawed, how could a capability-safe language do anything to correct the problem? It is my assertion that the design of Linux, Windows, MacOS are all…

> An Operating System is a program that multiplexes hardware resources and makes them safely usable by a number of applications. If the design of that system is flawed, how could a capability-safe language do anything to correct the problem?

A capability-safe language safely multiplexes hardware and software resources among different parts of the same application. So, even if every application has the privilege to crash your computer, delete all your files, or exfiltrate your Bitcoin and ssh keys, not all the code in the application would. For example, your logging library doesn't need those authorities, so the rest of the program wouldn't pass them in.

> Memory safe, and even capability safe languages won't do any good, if the underlying OS doesn't enforce the will of the user, but instead freely gives the users authority to any program they happen to run, intentional or otherwise.

It is necessary to enforce the user's desired limits the authority on each application to prevent damage from malicious applications, but capability-safe languages (or hardware, like CHERI) can in most cases prevent damage from confused applications and from confused or malicious libraries.

> I'm not saying memory or capability safety isn't useful, I'm just saying it isn't sufficient.

I agree, but capability safety properly integrated with the user interface may be sufficient, as long as the capability system is sufficiently expressive to express the will of the user. (For example, KeyKOS's capability system includes keys to use limited amounts of CPU time, while E has no effective way to keep malicious code from denying access to a whole vat once it starts running; killing a running process because they're using too much CPU or memory requires some way to recover from their failures, which E does not have.)

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

#142

Post by kragen »

pdimitar wrote: post #124
kragen wrote: post #115

Earlier quoted context omitted.

You're going to have a hard time getting a job writing E, or for that matter finding E libraries, because nobody uses E. Same story with Lobster, Clean, RScheme, Cobra, or a zillion other languages that don't have much adoption. But that is an entirely separate question from it being a cumbersome programming language, which is what the grandparent comment was alleging of all ocap languages—based on, apparently, total…

I don't disagree but we have to start somewhere . For example: formally specify [the clear parts of] HTTP 1.1 with declarative programming (which will generate proper code) and that would already be a huge jump. My point is: at one point somebody has to contribute.

You may have intended to comment on a different article, since not only does your comment not relate to anything in my comment it was related to, it doesn't relate to the security approach being discussed in the article the entire thread is about.

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

#143

Post by kragen »

DarkmSparks wrote: post #119
fiddlerwoaroof wrote: post #63

Earlier quoted context omitted.

This is more like ACLs, which are a completely different paradigm from capability-based security. An ACL system is based around specifying permissions for actions and such, whereas capability systems are based around reifying authority in an unforgeable way and passing the resulting tokens around.

I don't see the difference between passing tokens around and inheriting a security manager that can only have permissions and capabilities revoked?

You should probably spend ten minutes reading an introduction to capabilities then so you can understand the basic concepts before commenting. I don't know what to recommend nowadays, but mlinksva posted a link to one.

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

#144

Post by kragen »

monocasa wrote: post #25
armchairhacker wrote: post #11

Earlier quoted context omitted.

It still passes. Because JNDI would require network access, so log4j would also have to require network access or "disable" the network capability.

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.

A capability-secure language would keep log4j from getting access to the IPC channel to the JNDI process, unless log4j's caller specifically passed log4j the JNDI IPC channel capability.

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

#145

Post by DarkmSparks »

samus wrote: post #133
DarkmSparks wrote: post #119

Earlier quoted context omitted.

I don't see the difference between passing tokens around and inheriting a security manager that can only have permissions and capabilities revoked?

The former is explicit, and an IDE can help with highlighting unused ones. The latter is difficult to audit because the code that uses relevant APIs is disconnected from the privilege-enforcing mechanism. It's either some sort of abstract policy framework or explicit privilege dropping

I don't remotely see how an ide could help highlight which functions are insecure to call reflectively, other than linting, and that applies to both and only helps so much.

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

#146

Post by DarkmSparks »

kragen wrote: post #143
DarkmSparks wrote: post #119

Earlier quoted context omitted.

I don't see the difference between passing tokens around and inheriting a security manager that can only have permissions and capabilities revoked?

You should probably spend ten minutes reading an introduction to capabilities then so you can understand the basic concepts before commenting. I don't know what to recommend nowadays, but mlinksva posted a link to one.

I wasnt the one saying security manager was the same as an acl.

Nothing you posted explains why a reference to the security manager class isn't a token.

It seems to me more that you dont understand either capabilities or the old security manager class.

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

#147

Post by Zababa »

continuational wrote: post #139
Zababa wrote: post #131

Earlier quoted context omitted.

Thank you for the example, that helps a lot. So for example, when you write a library that need capabilities, you would write it using dependency (capability?) injection, and then the main program would have to pass an object with that capability for the code to work? And I see what you mean by "they are just plain values, and require nothing special from the type system", as long as you restrict what part of the pro…

Yes, dependency injection (without DI frameworks) is pretty much what it is! Just taken a bit further to the logical conclusion. I would point to an online resource, but honestly I haven't run across any that does justice to the simplicity of the concept.

I'd say our conversation right here is a good example. Most people understand static typing, most people understand DI. Once you have those, the only part left to understand is the concept of capabilities. If you have all of those, your example is clear and simple. Maybe adding a type annotation to show that fs is a FileSystem in main, but that's about it.

I think you've done a good job of minimizing what's required for the average developer to go from not knowing about capabilities to using them.

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

#148

Post by alasdair_ »

kragen wrote: post #111
alasdair_ wrote: post #108

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 e…

It sounds like you haven't tried it, so you're just guessing that it would be hard without any knowledge, because you're used to writing code in such a way that security is inconvenient. Writing code in E is nothing like writing formally verified code. It's a lot less work than writing code in Java or C++.

> Writing code in E is nothing like writing formally verified code. It's a lot less work than writing code in Java or C++.

I bet it’s not, for the very simple reason that most software today isn’t written in E.

This sounds like I’m being flippant but I’m not. The total “cost” of writing code in a specific language includes things like “can I find the answer on Stack Overflow?” and “can I hire enough engineers to code in this language?” And the total cost of coding in E is almost certainly higher than in Java because if it wasn’t, people would already be doing it.

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

#149

Post by kragen »

DarkmSparks wrote: post #146
kragen wrote: post #143

Earlier quoted context omitted.

You should probably spend ten minutes reading an introduction to capabilities then so you can understand the basic concepts before commenting. I don't know what to recommend nowadays, but mlinksva posted a link to one.

I wasnt the one saying security manager was the same as an acl. Nothing you posted explains why a reference to the security manager class isn't a token. It seems to me more that you dont understand either capabilities or the old security manager class.

> It seems to me more that you dont understand either capabilities or

Mark Miller cited me ("K. Sitaker") in Capability Myths Demolished and Paradigm Regained:

https://www-users.cselabs.umn.edu/classes/Fall-2019/csci5271...

https://www.hpl.hp.com/techreports/2003/HPL-2003-222.pdf?jum...

Tyler Close cited me in ACLs Don't:

https://www.hpl.hp.com/techreports/2009/HPL-2009-20.pdf?q=do....

It sounds like you disagree with their judgment on this point.

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

#150

Post by kragen »

alasdair_ wrote: post #148
kragen wrote: post #111

Earlier quoted context omitted.

It sounds like you haven't tried it, so you're just guessing that it would be hard without any knowledge, because you're used to writing code in such a way that security is inconvenient. Writing code in E is nothing like writing formally verified code. It's a lot less work than writing code in Java or C++.

> Writing code in E is nothing like writing formally verified code. It's a lot less work than writing code in Java or C++. I bet it’s not, for the very simple reason that most software today isn’t written in E. This sounds like I’m being flippant but I’m not. The total “cost” of writing code in a specific language includes things like “can I find the answer on Stack Overflow?” and “can I hire enough engineers to code…

I explained why your comment is not to the point 15 hours before you wrote it at https://news.ycombinator.com/item?id=29700919, because someone else already wrote the same thing.
Post reply on HN