JEP 411: Updates to alternatives

[Peter Firmstone]

Noticing the updates made to JEP 411 Alternatives, I think I might have 
a minimalist alternative, you may find interesting:

Remove:

 1. SecurityManager
 2. Policy provider and implementation
 3. Permission checks in JDK code addressed by improvements to
    encapsulation, eg RuntimePermission "access class in package" and 
    ReflectPermission, these are no longer necessary, however I would
    recommend retaining checks at System::getProperty and setProperty,
    as these may contain security sensitive information (eg keystore and
    truststore).
 4. doPrivileged calls within the JVM other than those which preserve
    context across threads, most permissions that "leak" are addressed
    at #3 above, and POLP tooling can capture other permissions.  It
    would appear that doPrivileged is more appropriate for application
    code, rather than JDK code.
 5. I'm not sure about removing doPrivileged calls intended to preserve
    context within OpenJDK.

Changes (improvements):

 1. Make Guard::check a default method, that delegates to a provider,
    with a single method (eg Authority::confirm(Guard)) that does
    nothing by default.  Remove all implementing instances of
    Permission::check. (this could be backported easily).
    SecurityManager methods are just permission checks, existing use
    cases of SecurityManager can be supported with this one method.  
    This could be back ported to Java 8, so libraries that currently
    support all supported Java versions can continue to do so.  All
    calls to SecurityManager methods in JDK code can be replaced by the
    corresponding permission check.
 2. Add permission checks to data parsers (eg deserialization), this
    allows implementations to grant these permissions only to users, if
    there is not an authenticated user, then the data received by the
    parser cannot be trusted.
 3. "Modules that are mapped to the boot loader get a unique
    ProtectionDomain that includes a useful code source rather than
    using a "shared" PD."   This allows permission to be granted to
    users, (not code) so certain privileged operations, such as data
    parsing cannot be performed without an authenticated user, eg
    deserialization.  When data can only be trusted from authenticated
    users.

Removal of AccessController and AccessControlContext have greater 
impact.   AccessController's stack walk is high scaling (I haven't 
observed any contention, I assume it's non blocking and thread 
confined?), it's certainly very performant, it could be replaced 
internally by StackWalker to reduce OpenJDK's maintenance burden, 
although it isn't clear what the performance impact might be, but it 
will no doubt performance improvement is possible.

With SecurityManager gone, no implementation and no policy provider, it 
simply provides the mechanics for an authorization layer without all the 
baggage, allowing both simple and complex implementations.  It's not for 
sandboxing untrusted code. Improvements will allow it to be utilised by 
developers, to prevent consumption of untrusted code or data and to 
limit the privileges of trusted code and users to principles of least 
privilege.

It should also simplifies many tests, as JDK code only need confirm 
Permission checks are made and functionality of the AccessController and 
AccessControlContext methods if these are retained (I would prefer to 
see that, at least for JAAS compatibility).

-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210612/53d81340/attachment.htm>