Re: Authorization Layer post JEP 411
Sean, Also moving forward we currently preserve AccessControlContext across threads, and we do this to establish TLS connections for call backs. Will there be a new way to preserve the calling Subject across threads, so we can perform callbacks over TLS? Regards, -- Regards, Peter Firmstone On 4/06/2021 7:39 am, Peter Firmstone wrote: Hi Sean, Developers are still going to need single points of control, where we can attach our agents to Java's API's. We can't be playing a game of whack a mole trying to lock down the JDK. It's fair enough that OpenJDK no longer wishes to maintain SecurityManager, however there are those of us who have to implement authorization layers and access controls and we don't have the luxury of choice. So we've established that we need to use Agents and StackWalker now to implement our authorization layer. It will be some years before we are able to keep up to date with Java releases again, but now we need to focus on how to achieve that. Regarding your questions, the performance problems, were related to Java's FilePolicy implementation, I solved those issues by replacing it, but you're already aware of that, I was highlighting the struggle that developers have with Java security, but also that JAAS is a common foundation for user authorisation, so I hope that it will be improved, rather than removed. I of course also use JAAS to establish TLS connections. If there's anything else OpenJDK is thinking about, thinking about removing, then we need to know, so we don't use them in our new authorization layer.
Re: Authorization Layer post JEP 411
Hi Sean, Developers are still going to need single points of control, where we can attach our agents to Java's API's. We can't be playing a game of whack a mole trying to lock down the JDK. It's fair enough that OpenJDK no longer wishes to maintain SecurityManager, however there are those of us who have to implement authorization layers and access controls and we don't have the luxury of choice. So we've established that we need to use Agents and StackWalker now to implement our authorization layer. It will be some years before we are able to keep up to date with Java releases again, but now we need to focus on how to achieve that. Regarding your questions, the performance problems, were related to Java's FilePolicy implementation, I solved those issues by replacing it, but you're already aware of that, I was highlighting the struggle that developers have with Java security, but also that JAAS is a common foundation for user authorisation, so I hope that it will be improved, rather than removed. I of course also use JAAS to establish TLS connections. If there's anything else OpenJDK is thinking about, thinking about removing, then we need to know, so we don't use them in our new authorization layer. -- Regards, Peter Firmstone On 4/06/2021 1:02 am, Sean Mullan wrote: On 6/2/21 7:41 PM, Peter Firmstone wrote: AccessController and AccessControlContext allow backward compatiblity for JAAS. JAAS whether we like it or not, is the default authorisation layer framework. http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/ I'm not sure why you referenced this blog which is actually advocating that JAAS has *less* dependency on Security Manager APIs such as AccessControlContext, whereas you seem to be advocating the opposite. In any case, I believe the first two issues in this blog will largely be addressed by the deprecation of the Security Manager and the JAAS related RFEs that we have filed as follow-on work to JEP 411 to remove the dependencies on the SM APIs: https://bugs.openjdk.java.net/browse/JDK-8266592 https://bugs.openjdk.java.net/browse/JDK-8267108 As for the 3rd issue in the blog, it is not related to the Security Manager, but I would need more time to understand the issues that were described. Also the blog was written by David Lloyd who has been participating in these discussions, so he may want to say more about it. --Sean
Re: Authorization Layer post JEP 411
On 6/2/21 7:41 PM, Peter Firmstone wrote: AccessController and AccessControlContext allow backward compatiblity for JAAS. JAAS whether we like it or not, is the default authorisation layer framework. http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/ I'm not sure why you referenced this blog which is actually advocating that JAAS has *less* dependency on Security Manager APIs such as AccessControlContext, whereas you seem to be advocating the opposite. In any case, I believe the first two issues in this blog will largely be addressed by the deprecation of the Security Manager and the JAAS related RFEs that we have filed as follow-on work to JEP 411 to remove the dependencies on the SM APIs: https://bugs.openjdk.java.net/browse/JDK-8266592 https://bugs.openjdk.java.net/browse/JDK-8267108 As for the 3rd issue in the blog, it is not related to the Security Manager, but I would need more time to understand the issues that were described. Also the blog was written by David Lloyd who has been participating in these discussions, so he may want to say more about it. --Sean
Re: [External] : Authorization Layer post JEP 411
Yes, I think so too. However I will encourage developers to continue to take advantage of SM for improved security now, there's no need to rush to abandon it. Maybe in future there will be better alternatives, but it's the best option for those who are security focused now. With time no doubt hardening that will occur to the Java platform as OpenJDK responds to vulnerabilities, it will become the most secure option again, but I think that's a number of years away and I'd rather be conservative than get burned. If SM deprecation doesn't impact your use case, then yes I would encourage you to upgrade, because that's the sensible thing to do. I'll still test on later versions, but I won't be removing our authorization system until I'm satisfied there are sufficiently hardened alternative technologies available. Thank you, Peter. On 3/06/2021 7:58 pm, Ron Pressler wrote: It is certainly time to accept that JEP 411 has been accepted, and so that those who use Security Manager will need to do some work to change their software. The purpose of this and upcoming discussions is to find reasonable approaches that might relieve some portion of the burden on those who use SM today while not placing an undue (indirect) burden on those who do not. — Ron On 3 Jun 2021, at 10:43, Peter Firmstone wrote: Ok, thanks Ron, I think we are confirming that Java, post version 17, will not meet the security needs our software. It's time I accepted that and moved on. Thanks for your time. Have you seen my latest article on foojay? Feel free to comment and let me know what you think. https://urldefense.com/v3/__https://foojay.io/today/jep-411-what-it-means-for-javas-security-model/__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje9M4Wtv3A$ Cheers, Peter. On 3/06/2021 7:33 pm, Ron Pressler wrote: On 3 Jun 2021, at 00:41, Peter Firmstone wrote: StackWalker doesn't work with compiled code, only bytecode. If you’re referring to GraalVM’s Native Image, I don’t know about that problem and there does seem to be a relevant patch (https://urldefense.com/v3/__https://github.com/oracle/graal/pull/734__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje-DV8ldZw$ ), but Native Image is a separate project from OpenJDK. AccessController and AccessControlContext allow backward compatiblity for JAAS. JAAS whether we like it or not, is the default authorisation layer framework. https://urldefense.com/v3/__http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje-R7C-0Hg$ I don’t know how much a seven-year-old article, that predates Java 8 supports the use of the present tense, but in any event, the JEP says that JAAS will be preserved. With SecurityManager gone, people will no longer assume it has sole responsible for Security People don’t assume that now, as secure software doesn’t employ it even today. People do, however, assume that the mechanism, if used, is robust enough to be used for security purposes. OpenJDK devs won't carry a significant burden for it's maintenance. While the number of places where the JDK *implements* some “protected operation”, like opening a file or writing to a socket, is somewhat bounded — and so keeping some hooks in those places *might* be reasonable — the number of places that *use* those operations is not. Maintaining doPrivileged in that unbounded set of places is not an insignificant burden. Any security issues will be the responsibility of third party implementations, like mine. The JDK won't provide an implementation, just the framework. But the correct use of doPrivileged, if you’re proposing that it’s kept, must still be tested against *some* implementation, and OpenJDK would still need to fix bugs related to it. Those of us using the Principle of Least Privilege can continue to do so Perhaps you believe that the only software in the world that applies Least Privilege is Java software that employs the Security Manager, but that is not how most people, including the person who had framed it two decades prior to the invention of the Security Manager, understand the principle. The original statement of the principle was: "Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.” (https://urldefense.com/v3/__https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.226.3939__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje-xd8krsA$ ) You are talking about applying the principle at a granularity of code units that are smaller than a program. It’s fine to believe that is worthwhile, but the principle certainly doesn’t require that every effort be expended to afford least privilege at any granularity. and we can participate in OpenJDK to maintain Permission checks where we need
Re: [External] : Authorization Layer post JEP 411
It is certainly time to accept that JEP 411 has been accepted, and so that those who use Security Manager will need to do some work to change their software. The purpose of this and upcoming discussions is to find reasonable approaches that might relieve some portion of the burden on those who use SM today while not placing an undue (indirect) burden on those who do not. — Ron > On 3 Jun 2021, at 10:43, Peter Firmstone wrote: > > Ok, thanks Ron, > > I think we are confirming that Java, post version 17, will not meet the > security needs our software. It's time I accepted that and moved on. > > Thanks for your time. > > Have you seen my latest article on foojay? Feel free to comment and let me > know what you think. > > https://urldefense.com/v3/__https://foojay.io/today/jep-411-what-it-means-for-javas-security-model/__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje9M4Wtv3A$ > > Cheers, > > Peter. > > > On 3/06/2021 7:33 pm, Ron Pressler wrote: >> >>> On 3 Jun 2021, at 00:41, Peter Firmstone >>> wrote: >>> >>> >>> StackWalker doesn't work with compiled code, only bytecode. >> If you’re referring to GraalVM’s Native Image, I don’t know about that >> problem and >> there does seem to be a relevant patch >> (https://urldefense.com/v3/__https://github.com/oracle/graal/pull/734__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje-DV8ldZw$ >> ), but >> Native Image is a separate project from OpenJDK. >> >>> AccessController and AccessControlContext allow backward compatiblity for >>> JAAS. JAAS whether we like it or not, is the default authorisation layer >>> framework. >>> >>> https://urldefense.com/v3/__http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje-R7C-0Hg$ >>> >> I don’t know how much a seven-year-old article, that predates Java 8 >> supports the use >> of the present tense, but in any event, the JEP says that JAAS will be >> preserved. >> >>> With SecurityManager gone, people will no longer assume it has sole >>> responsible for Security >> People don’t assume that now, as secure software doesn’t employ it even >> today. People do, >> however, assume that the mechanism, if used, is robust enough to be used for >> security >> purposes. >> >>> OpenJDK devs won't carry a significant burden for it's maintenance. >> While the number of places where the JDK *implements* some “protected >> operation”, like >> opening a file or writing to a socket, is somewhat bounded — and so keeping >> some hooks >> in those places *might* be reasonable — the number of places that *use* >> those operations >> is not. Maintaining doPrivileged in that unbounded set of places is not an >> insignificant >> burden. >> >> >>> Any security issues will be the responsibility of third party >>> implementations, like mine. >>> The JDK won't provide an implementation, just the framework. >> But the correct use of doPrivileged, if you’re proposing that it’s kept, >> must still be >> tested against *some* implementation, and OpenJDK would still need to fix >> bugs related >> to it. >> >>> Those of us using the Principle of Least Privilege can continue to do so >> Perhaps you believe that the only software in the world that applies Least >> Privilege is >> Java software that employs the Security Manager, but that is not how most >> people, including >> the person who had framed it two decades prior to the invention of the >> Security Manager, >> understand the principle. >> >> The original statement of the principle was: "Every program and every >> privileged user of >> the system should operate using the least amount of privilege necessary to >> complete the >> job.” >> (https://urldefense.com/v3/__https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.226.3939__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje-xd8krsA$ >> ) >> >> You are talking about applying the principle at a granularity of code units >> that are >> smaller than a program. It’s fine to believe that is worthwhile, but the >> principle >> certainly doesn’t require that every effort be expended to afford least >> privilege at >> any granularity. >> >>> and we can participate in OpenJDK to maintain Permission checks where we >>> need them and preserve context where appropriate. >> I think you’re underestimating the magnitude of this work, which potentially >> interacts with >> each and every change in the JDK (and in practice interacts with many of >> them, and today it’s >> done by those who are responsible for the relevant change), which you’ll >> need to monitor, >> not to mention that OpenJDK Reviewers, a role granted only to the most >> experienced contributors, >> would still have to review that work. >> >> However, if you think that is an amount of work you could manage, perhaps it >> could be done >> outside the JDK
Re: [External] : Authorization Layer post JEP 411
Ok, thanks Ron, I think we are confirming that Java, post version 17, will not meet the security needs our software. It's time I accepted that and moved on. Thanks for your time. Have you seen my latest article on foojay? Feel free to comment and let me know what you think. https://foojay.io/today/jep-411-what-it-means-for-javas-security-model/ Cheers, Peter. On 3/06/2021 7:33 pm, Ron Pressler wrote: On 3 Jun 2021, at 00:41, Peter Firmstone wrote: StackWalker doesn't work with compiled code, only bytecode. If you’re referring to GraalVM’s Native Image, I don’t know about that problem and there does seem to be a relevant patch (https://github.com/oracle/graal/pull/734), but Native Image is a separate project from OpenJDK. AccessController and AccessControlContext allow backward compatiblity for JAAS. JAAS whether we like it or not, is the default authorisation layer framework. http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/ I don’t know how much a seven-year-old article, that predates Java 8 supports the use of the present tense, but in any event, the JEP says that JAAS will be preserved. With SecurityManager gone, people will no longer assume it has sole responsible for Security People don’t assume that now, as secure software doesn’t employ it even today. People do, however, assume that the mechanism, if used, is robust enough to be used for security purposes. OpenJDK devs won't carry a significant burden for it's maintenance. While the number of places where the JDK *implements* some “protected operation”, like opening a file or writing to a socket, is somewhat bounded — and so keeping some hooks in those places *might* be reasonable — the number of places that *use* those operations is not. Maintaining doPrivileged in that unbounded set of places is not an insignificant burden. Any security issues will be the responsibility of third party implementations, like mine. The JDK won't provide an implementation, just the framework. But the correct use of doPrivileged, if you’re proposing that it’s kept, must still be tested against *some* implementation, and OpenJDK would still need to fix bugs related to it. Those of us using the Principle of Least Privilege can continue to do so Perhaps you believe that the only software in the world that applies Least Privilege is Java software that employs the Security Manager, but that is not how most people, including the person who had framed it two decades prior to the invention of the Security Manager, understand the principle. The original statement of the principle was: "Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.” (https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.226.3939) You are talking about applying the principle at a granularity of code units that are smaller than a program. It’s fine to believe that is worthwhile, but the principle certainly doesn’t require that every effort be expended to afford least privilege at any granularity. and we can participate in OpenJDK to maintain Permission checks where we need them and preserve context where appropriate. I think you’re underestimating the magnitude of this work, which potentially interacts with each and every change in the JDK (and in practice interacts with many of them, and today it’s done by those who are responsible for the relevant change), which you’ll need to monitor, not to mention that OpenJDK Reviewers, a role granted only to the most experienced contributors, would still have to review that work. However, if you think that is an amount of work you could manage, perhaps it could be done outside the JDK using Java Agents. JAAS will continue to remain functional The JEP already intends to keep JAAS functional, as far as I can tell. — Ron
Re: [External] : Authorization Layer post JEP 411
> On 3 Jun 2021, at 00:41, Peter Firmstone wrote: > > > StackWalker doesn't work with compiled code, only bytecode. If you’re referring to GraalVM’s Native Image, I don’t know about that problem and there does seem to be a relevant patch (https://github.com/oracle/graal/pull/734), but Native Image is a separate project from OpenJDK. > > AccessController and AccessControlContext allow backward compatiblity for > JAAS. JAAS whether we like it or not, is the default authorisation layer > framework. > > http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/ I don’t know how much a seven-year-old article, that predates Java 8 supports the use of the present tense, but in any event, the JEP says that JAAS will be preserved. > > With SecurityManager gone, people will no longer assume it has sole > responsible for Security People don’t assume that now, as secure software doesn’t employ it even today. People do, however, assume that the mechanism, if used, is robust enough to be used for security purposes. > OpenJDK devs won't carry a significant burden for it's maintenance. While the number of places where the JDK *implements* some “protected operation”, like opening a file or writing to a socket, is somewhat bounded — and so keeping some hooks in those places *might* be reasonable — the number of places that *use* those operations is not. Maintaining doPrivileged in that unbounded set of places is not an insignificant burden. > Any security issues will be the responsibility of third party > implementations, like mine. > The JDK won't provide an implementation, just the framework. But the correct use of doPrivileged, if you’re proposing that it’s kept, must still be tested against *some* implementation, and OpenJDK would still need to fix bugs related to it. > > Those of us using the Principle of Least Privilege can continue to do so Perhaps you believe that the only software in the world that applies Least Privilege is Java software that employs the Security Manager, but that is not how most people, including the person who had framed it two decades prior to the invention of the Security Manager, understand the principle. The original statement of the principle was: "Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.” (https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.226.3939) You are talking about applying the principle at a granularity of code units that are smaller than a program. It’s fine to believe that is worthwhile, but the principle certainly doesn’t require that every effort be expended to afford least privilege at any granularity. > and we can participate in OpenJDK to maintain Permission checks where we need > them and preserve context where appropriate. I think you’re underestimating the magnitude of this work, which potentially interacts with each and every change in the JDK (and in practice interacts with many of them, and today it’s done by those who are responsible for the relevant change), which you’ll need to monitor, not to mention that OpenJDK Reviewers, a role granted only to the most experienced contributors, would still have to review that work. However, if you think that is an amount of work you could manage, perhaps it could be done outside the JDK using Java Agents. > > JAAS will continue to remain functional The JEP already intends to keep JAAS functional, as far as I can tell. — Ron
Re: Authorization Layer post JEP 411
On 03/06/2021 08:28, Peter Firmstone wrote:
Apologies, I meant when compiled to native code, when you ship native
binaries.
I'm not sure what you mean here. Are you talking about native binaries
as generated by the GraalVM Native Image Generator? If you are
suggesting there is a disparity in behaviour between any such image and
the original app running on the JVM - whether specifically with respect
to how the stack walk APIs operate or more generally -- then I'd be
very interested to know the full details.
Note however that were any such disparity to exist then there is no onus
on the OpenJDK project to react to it. OpenJDK is based on a well
defined standard and is not beholden to decisions made by other projects
about how to translate Java code into a delivered executable.
Having said that, if it's necessary to use StackWalker behind
AccessController.doPrivileged going forward then lets do so, and maybe
the native binary is a later feature.
Hopefully my proposal is getting some consideration.
If you are proposing a change to Java then I think recommend that you
propose it relative to the current reference implementation of the Java
Language (and JVM) standards i.e. OpenJDK.
regards,
Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
Re: Authorization Layer post JEP 411
Apologies, I meant when compiled to native code, when you ship native binaries. Having said that, if it's necessary to use StackWalker behind AccessController.doPrivileged going forward then lets do so, and maybe the native binary is a later feature. Hopefully my proposal is getting some consideration. -- Regards, Peter. On 3/06/2021 5:18 pm, Alan Bateman wrote: On 03/06/2021 01:04, Chapman Flack wrote: On 06/02/21 19:41, Peter Firmstone wrote: We need the power of AccessController's stack walk, StackWalker doesn't work with compiled code, only bytecode. Is this correct? I have not tried it, but the apidocs had led me to understand it did not distinguish much between JITed and interpreted code. Even getByteCodeIndex does not mention any limitation when the frame is JITed Java code (though it does say it will return a negative number in the distinct case of an actual native method). There should be no issue here. I suspect Peter meant that the stack walker is about walking Java frames, it's transparent whether there are interpreter frames, compiled frame, or a mix on the stack. -Alan
Re: Authorization Layer post JEP 411
On 03/06/2021 01:04, Chapman Flack wrote: On 06/02/21 19:41, Peter Firmstone wrote: We need the power of AccessController's stack walk, StackWalker doesn't work with compiled code, only bytecode. Is this correct? I have not tried it, but the apidocs had led me to understand it did not distinguish much between JITed and interpreted code. Even getByteCodeIndex does not mention any limitation when the frame is JITed Java code (though it does say it will return a negative number in the distinct case of an actual native method). There should be no issue here. I suspect Peter meant that the stack walker is about walking Java frames, it's transparent whether there are interpreter frames, compiled frame, or a mix on the stack. -Alan
Re: Authorization Layer post JEP 411
On 06/02/21 19:41, Peter Firmstone wrote: > We need the power of AccessController's stack walk, StackWalker doesn't work > with compiled code, only bytecode. Is this correct? I have not tried it, but the apidocs had led me to understand it did not distinguish much between JITed and interpreted code. Even getByteCodeIndex does not mention any limitation when the frame is JITed Java code (though it does say it will return a negative number in the distinct case of an actual native method). Regards, -Chap
Authorization Layer post JEP 411
A comment from Ron highlites our issue: the JDK contains only things that either only the JDK can technically do We have a need to distinguish between different sources of code, as well as user principles, and as well as Services. Our services are loaded by separate ClassLoaders and are to some extent sandboxed as Ron's example suggests. And we have a need to control access based on these entities. We have always strived to be cross platform and tested on other JVM's such as J9. It's just very hard to see any solutions without AccessController and AccessControlContext. We don't need SecurityManager (although we still need a Policy provider, because ProtectionDomain calls it, but we don't need a policy implementation, just the provider, feel free to remove Java's PolicyFile implementation), if we added a provider interface to Guard.check and changed all permission checks to call their superclass method Guard.check. That authorization layer provider could be called Authority and it can have one single method: Authority::confirm(Permission p) throws SecurityException; We need the power of AccessController's stack walk, StackWalker doesn't work with compiled code, only bytecode. AccessController and AccessControlContext allow backward compatiblity for JAAS. JAAS whether we like it or not, is the default authorisation layer framework. http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/ We could create a new property that bypasses the AccessController's stack walk for those who don't need to control CodeSource access. (Just create a ProtectionDomain containing a Subject). Benefits: With SecurityManager gone, people will no longer assume it has sole responsible for Security and OpenJDK devs won't carry a significant burden for it's maintenance. Any security issues will be the responsibility of third party implementations, like mine. The JDK won't provide an implementation, just the framework. Those of us using the Principle of Least Privilege can continue to do so and we can participate in OpenJDK to maintain Permission checks where we need them and preserve context where appropriate. JAAS will continue to remain functional and it's performance will increase significantly (it performs very well with my Policy implementation, even with stack walks). -- Regards, Peter Firmstone Zeus Project Services Pty Ltd.
