PrivilegedAction et al and JEP411

[Peter Firmstone]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230618/812e564e/attachment.htm>