Authorization Layer post JEP 411

[Peter Firmstone]

A comment from Ron highlites our issue:

> the JDK contains only things that either only the JDK can technically do

We have a need to distinguish between different sources of code, as well 
as user principles, and as well as Services.   Our services are loaded 
by separate ClassLoaders and are to some extent sandboxed as Ron's 
example suggests.

And we have a need to control access based on these entities.

We have always strived to be cross platform and tested on other JVM's 
such as J9.

It's just very hard to see any solutions without AccessController and 
AccessControlContext.

We don't need SecurityManager (although we still need a Policy provider, 
because ProtectionDomain calls it, but we don't need a policy 
implementation, just the provider, feel free to remove Java's PolicyFile 
implementation), if we added a provider interface to Guard.check and 
changed all permission checks to call their superclass method Guard.check.

That authorization layer provider could be called Authority and it can 
have one single method:

Authority::confirm(Permission p) throws SecurityException;

We need the power of AccessController's stack walk, StackWalker doesn't 
work with compiled code, only bytecode.

AccessController and AccessControlContext allow backward compatiblity 
for JAAS.   JAAS whether we like it or not, is the default authorisation 
layer framework.

http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/

We could create a new property that bypasses the AccessController's 
stack walk for those who don't need to control CodeSource access. (Just 
create a ProtectionDomain containing a Subject).

Benefits:

With SecurityManager gone, people will no longer assume it has sole 
responsible for Security and OpenJDK devs won't carry a significant 
burden for it's maintenance.  Any security issues will be the 
responsibility of third party implementations, like mine.

The JDK won't provide an implementation, just the framework.

Those of us using the Principle of Least Privilege can continue to do so 
and we can participate in OpenJDK to maintain Permission checks where we 
need them and preserve context where appropriate.

JAAS will continue to remain functional and it's performance will 
increase significantly (it performs very well with my Policy 
implementation, even with stack walks).

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

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