Revisiting encapsulation requirement

[David M. Lloyd]

Do you have an example of a real-world problem (security or otherwise) 
that is solved by adding access checks based on the caller?

On 09/15/2015 10:52 AM, Remi Forax wrote:
> Hi David,
> I don't think we should modify the "encapsulation" requirement if the requirement
> only apply to regular Java code and not on reflection + setAccessible(true).
>
> Currently, when you use reflection, you have the same security checks as in plain Java,
> and you can bypass those security checks using setAccessible(true).
>
> I don't see why we should change that:
>    - Class.forName() should throw a ClassNotFoundException if the module of the class is not declared as dependency.
>    - invoke() should throw a an IllegalAccess exception if the module of the class is not declared as dependency.
>    - setAccessible() should allow to bypass the security check and works as in pre-module world.
>
> I don't see the point to either add a new security check on setAccessible or to allow reflection between modules that are not listed in the dependencies.
>
> Rémi
>
> ----- Mail original -----
>> De: "David M. Lloyd" <david.lloyd at redhat.com>
>> À: jpms-spec-experts at openjdk.java.net
>> Envoyé: Mardi 15 Septembre 2015 14:01:07
>> Objet: Revisiting encapsulation requirement
>>
>> Experts, I think we should revisit the "Encapsulation" requirement with
>> a view towards removal.
>>
>> The requirement is:
>>
>>> Encapsulation — The access-control mechanisms of the Java language and
>>> virtual machine must prevent code from accessing classes and interfaces in
>>> packages that are not exported by their containing modules, or in packages
>>> whose containing modules are not required by the module containing the
>>> code. These mechanisms must be operative even when a security manager is
>>> not present.
>>
>> The implementation amounts to modifying the
>> AccessibleObject.setAccessible() implementation for classes to perform a
>> check of the caller's class loader before determining whether to make
>> the object accessible.
>>
>> As Rémi pointed out, this check is easily bypassed by using reflection,
>> by reflecting on AccessibleObject.class itself - since all modules
>> require "java.base", all modules implicitly can bypass this check.  But,
>> even assuming this could somehow be patched over, I think we should
>> consider dropping this requirement; I have two primary reasons for this
>> (though there may be others as well).
>>
>> The first reason is that without a security manager (or maybe even
>> *with* a security manager - but that's another discussion), it is
>> inevitable that any security measure used to protect this mechanism will
>> ultimately be bypassed, rendering its security value useless; adding
>> more complexity to the system to do so will only increase the overall
>> vulnerability of the platform.
>>
>> The second reason is that it is often useful to gain access to and
>> inspect public classes that are not necessarily visible from your
>> module.  Frameworks do this commonly for example - framework
>> implementations will almost never import modules that they introspect.
>>
>> I think in the end users will find it more convenient and intuitive (and
>> no less secure in any real sense) if public classes remain accessible.
>> In the absence of any dissent, I would move that we drop this requirement.
>>
>> --
>> - DML
>>

-- 
- DML