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
