Thanks Alan,
Personally, I would hope that nothing happens until after Java 21, time
is precious, we'll need all the time we can get.
I was hoping, that all privileged actions might be retained
indefinitely, so that we may instrument them. Perhaps in future they
may also have other uses with Subject.
I only ask that we be allowed the opportunity to build a better
authorization framework (we have to build one, but I'd like it to be an
improvement, rather than a compromise), there have been many lessons
learned from Li Gong's work. I think I've demonstrated what's possible
with JGDMS. Previously, I've only been able to work around the
problems in OpenJDK, as a downstream developer, but within the JDK,
there is so much more opportunity. Beyond any doubt, concurrency was a
far greater challenge than authorization ever was and look how good
concurrency is today.
The three design issues, fix these and maintenance is significantly
reduced (I couldn't solve these as a downstream developer):
1. Privileged calls need to be short and sweet, outside of privileged
calls, there should be zero privileges, this addresses viral
permissions.
2. The trusted computing base is far too large, it should be limited to
a small part of the Java platform.
3. Parsing of remote data required permission checks, to allow
decisions to parse based on trust with the remotely authenticated
subject, this could have prevented the much of the de-serialization
security debacle in server side programming, similar to how
Elasticsearch avoided the log2j problem.
4. Make it easy to set up and use (I was able to mostly solve this with
tooling).
I certainly solved the performance issues and wrote tools to generate
policy files, which made life a lot easier.
Personally I'd like to replace all blocks with
System::getSecurityManager and permission checks, with
Guard::checkGuard, as it would allow us to instrument guards too, while
also allowing a level of indirection to simplify the removal of
SecurityManager as a no-op.
I've previously solved problems far more difficult than this. For
example, RMI has problems with class resolution, the original designers
tried to append codebase annotations within the marshalled streams,
performing class resolution during deserialization using RMIClassLoader.
https://web.archive.org/web/20060514011913/http://research.sun.com/technical-reports/2006/smli_tr-2006-149.pdf
To solve this problem, instead of annotating streams with codebase
annotations (a poor design), each Endpoint is assigned a ClassLoader,
following authentication, the ClassLoader at each endpoint is
responsible for class resolution of all deserialized classes of that
stream, stream based annotations are not required. Also separate
streams are created for different concerns, even when an object is
marshalled within a stream it doesn't belong to, a separate stream is
created, authenticated and established with appropriate ClassLoaders at
the Endpoints. RMIClassLoader was a design mistake, it wasn't needed,
ClassLoader already existed for class resolution, a duplicate class
resolution mechanism was never going to succeed. I also reimplemented
a subset of Java deserialization, using constructors with input
validation, it's immune to gadget attacks, it fails atomically when
input validation fails, no incomplete or partially constructed objects
are created, no need to create serial filters or whitelists, I looked at
de-serialization whitelists circa 2010, I chose not to implement them,
as it would have been brittle and cumbersome to maintain.
There were many difficult technical problems that prevented Sun's
success with Jini, today, every single one has been solved. JERI (Jini
Extensible Remote Invocation) today is a far superior framework than RMI
could ever hope to be, and yet, RMI is still used by Java, JERI could
replace it, which would allow the extensible replacement of Java
Serialization, that's hardwired into RMI. One day I would like to see
Java serialization, not as part of the base platform, but an add in
module for compatibility, that few need to use.
Not only did we solve technical issues with Jini, we made strides in
performance, Sun had a lot of DNS calls thanks to URL equals and
CodeSource implies methods, so Java was making lots of network calls,
OpenJDK still does, if you're using SecureClassLoader, URLClassLoader
and network URL's, performance is terrible. Instead we're using RFC3986
and RFC5952 normalization, and we're using bitshift operations for case
conversion in URI, because we had hotspots with string conversion during
URI normalization. We're going as fast as the hardware, network and JDK
allows, we only touch URL and DNS when we need to download something.
This is why sometimes we expose race conditions in Java's TLS
implementation, we made our software as concurrent and non blocking as
possible. We've also got global IPv6 multicast discovery, we have end
to end connectivity, we've got distributed network events and
distributed garbage collection, everything is authenticated, validated
and operating over secure network connections, it's all easily
configured and extensible. This isn't your publish subscribe web
service model. It turns out everything they dreamed of was possible, it
just required time to sort it out.
Comparatively, problems with Authorization are small and simple, easily
solved.
Thank you for your time and responses, I hope what I've said will be
considered.
--
Regards,
Peter
On 18/06/2023 6:21 pm, Alan Bateman wrote:
On 18/06/2023 02:28, Peter Firmstone wrote:
Curious to know OpenJDK's plans for removal of
AccessController::doPrivileged calls?
As JEP 411 alludes, the likely next step for this one is to degrade it
so that it just runs the action. This should be transparent to most
code, esp. library code that uses it so the library works when the
application is deployed with a security manager. Not early to say
which release a change like this might be proposed for.
-Alan
