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 <peter.firmst...@zeus.net.au> 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 <peter.firmst...@zeus.net.au> >>> 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 using Java Agents. >> >>> JAAS will continue to remain functional >> The JEP already intends to keep JAAS functional, as far as I can tell. >> >> — Ron >
