Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

[David M. Lloyd]

On 09/28/2016 04:37 AM, Gunnar Morling wrote:
>>  If I'm compiling a class A that has a reference to a member in type B
>> then do you really want the compiler calling into a security manager to
>> ask if this access is allowed?
>
> I don't think that is what those folks asking about using the SM had in
> mind.
>
> Rather, the idea would be - IIUC - to grant code in module B (say an ORM
> tool) reflective access to non-exported (and of course exported) types in
> module A (say a module with entities) by default. If needed, the code in B
> would then use setAccessible() for making private members in A accessible
> before invoking them, allowing it to obtain the entity state. This is where
> the SM is part of the picture: if in a given environment the user wants to
> restrict who may call setAccessible(), they could use the SM for it, with a
> fine grained policy, e.g. allowing the call only to the ORM module.
>
> I.e. ReflectiveAccessToNonExportedTypes would be granted by default, only
> if an SM is enabled at runtime, actions to suppress accessibility checks
> would be subject to the current security policy.
>
> This is not to say that I'm behind this idea, I just felt it hasn't been
> discussed in the way it may have been meant.
>
> I can see though how JDK devs and library authors want to prevent access to
> private code in their modules at all, hence relying on the SM to be enabled
> at runtime is not an option to address that requirement.

Note that as a security mechanism for untrusted code, this mechanism is 
not going to be adequate no matter what.  The person who has control of 
the deployment environment can always change the module to accommodate 
their case.  I'm sure it will be a very short time after finalization 
before we see module editing tools in the wild to accomplish exactly 
this.  This is an inevitable consequence of bundling the module 
definition within the module itself.

Only the JDK has any real ability to enforce this kind of security, 
though of course it's always possible to defeat that as well (it's just 
potentially a lot more work).

The chief tangible protection which is expected to be afforded by this 
mechanism is against malicious exploitation of trusted code.
-- 
- DML