Earlier quoted context omitted.
Just https://reviews.freebsd.org/D31923 ?
Yes.
Whew!
A capability-safe language would have minimized the Log4j vulnerability
151–158 of 158 posts
Re: A capability-safe language would have minimized the Log4j vulnerability
#152Earlier quoted context omitted.
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…
acls are only a tiny part of security manager did. It was a full fledged class based security system.
Yes, I do disagree that something like pfsense "is only an acl"
Or that capabilities can function without lists.
You dont?
Re: A capability-safe language would have minimized the Log4j vulnerability
#153Earlier quoted context omitted.
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…
Great! Maybe I can ask for your feedback once we've produced some documentation?
Re: A capability-safe language would have minimized the Log4j vulnerability
#154Earlier quoted context omitted.
> 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…
acls are only a tiny part of security manager did. It was a full fledged class based security system. Yes, I do disagree that something like pfsense "is only an acl" Or that capabilities can function without lists. You dont?
I'm not going to argue with you. You haven't earned it. Go and study.
Re: A capability-safe language would have minimized the Log4j vulnerability
#155Earlier quoted context omitted.
acls are only a tiny part of security manager did. It was a full fledged class based security system. Yes, I do disagree that something like pfsense "is only an acl" Or that capabilities can function without lists. You dont?
I'm not going to argue with you. You haven't earned it. Go and study.
You didnt argue. You just posted a load of completely irrelevant links that have absolutely nothing to do with the java security manager class or why it was depreciated in Java 17.
I believe there is a name for that - strawman.
the jep is here https://openjdk.java.net/jeps/411
Not checked but Im fairly certain none of your links are referenced there.
Re: A capability-safe language would have minimized the Log4j vulnerability
#156So 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…
We need to go even further for apps installed in mobile devices: We need to make it impossible for apps to determine that they've been denied a capability. Many useful apps refuse to run at all unless you give them access to personal information (e.g. your location) when there's no need for them to have such information to function. The solution is for the OS to spoof that capability by providing hostile apps with random data, or to otherwise fail to provide accurate data to the apps.
Of course a more ideal solution is for app stores to refuse to allow apps that list capabilities they cannot justify a need for, but at least in the Android world this doesn't seem to be happening.
Re: A capability-safe language would have minimized the Log4j vulnerability
#157Earlier quoted context omitted.
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…
Great! Maybe I can ask for your feedback once we've produced some documentation?
Yes, I would be very interested. My email address is in my profile.
Re: A capability-safe language would have minimized the Log4j vulnerability
#158Earlier quoted context omitted.
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…
If you're asking how th jvm might do it, I can assure you I do not know. If the question is "can this be a language feature" then I say, surely it can be. A language that supports static analysis and can disallow dynamic dispatch would do the trick, no?
There are ways to call a function that cannot be caught by static analysis: basically you just need a way to jump to an arbitrary address of memory where a particular function is stored. If we exclude languages that by design sandbox the code (for example JavaScript, and most of the time it isn't enough because engines are bugged and thus browsers also use facilities of the operating system to sandbox the entire engine itself) no other programming language can do that.