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.
