Exporting - the wrong default?

[Remi Forax]

----- Mail original -----
> De: "Alan Snyder" <javalists at cbfiddle.com>
> À: "David M. Lloyd" <david.lloyd at redhat.com>
> Cc: jigsaw-dev at openjdk.java.net
> Envoyé: Mercredi 27 Juillet 2016 23:17:10
> Objet: Re: Exporting - the wrong default?

> As a lurker to this discussion, I would like to express a casual opinion. I do
> not claim any original ideas here, nor do I claim to understand the details of
> the discussion.
> 
> I am skeptical of solutions that are motivated by security and yet are not
> secure. Echoing a previous comment, I would not want to lose functionality for
> something like that.
> 
> Is it considered irrelevant for security that native code can bypass all of
> these barriers?
> 
> 
> 
> I am wondering whether agreement could be reached on this general approach:
> 
>  1. modules that need unrestricted reflection (as in JDK 8) should declare that
>  desire in some static form (e.g. module info)

Creating your own module Layer let you to do that for all the modules but the ones of the JDK itself,
otherwise requiring jdk.unsupported (the module that own sun.misc.Unsafe) has that effect too
(see also https://bugs.openjdk.java.net/browse/JDK-8162494),

> 
>  2. a deployment time feature (e.g. command line argument) can be used to grant
>  unrestricted reflection privileges to specific modules (but only to those known
>  at deployment time)

You can do that with a Java Agent.

> 
>  3. build tools can offer the convenience of using #1 and #2 to give unrestricted
>  reflection privileges to every module known at deployment time that requests it

not sure what build tools means in that context.

> 
> 
> An implication is that modules that use unrestricted reflection should be
> carefully written so that malicious code could not hijack their reflective
> abilities to cause trouble. (The same would be the case for modules that use
> native code.)

yes,
with great power comes responsibility :)
All the runtimes of the languages that run on top of the JVM (Java included) has that issue.

> 
>  Alan
> 

Rémi

> 
> 
> 
>> On Jul 27, 2016, at 9:13 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> 
>> On 07/27/2016 10:26 AM, Remi Forax wrote:
>>> ----- Mail original -----
>>>> De: "dalibor topic" <dalibor.topic at oracle.com>
>>>> À: jigsaw-dev at openjdk.java.net
>>>> Envoyé: Mercredi 27 Juillet 2016 14:39:05
>>>> Objet: Re: Exporting - the wrong default?
>>> 
>>>> On 26.07.2016 18:42, Stephen Colebourne wrote:
>>>>> In many projects
>>>>> packages change names frequently during development, everything is
>>>>> open and locking stuff down is the last thing on peoples minds. While
>>>>> this of course leads to slightly less secure software, it does achieve
>>>>> *business value*.
>>>> 
>>>> I would recommend Cristina Cifuentes presentation "Are We Ready for
>>>> Secure Languages?" from the recent Curry On conference, of which a
>>>> recording is available at https://www.youtube.com/watch?v=-fC975HLhyc
>>>> for some less anecdotal thoughts on the business value of slightly more
>>>> secure software.
>>>> 
>>>> It even touches briefly on the utility of modules in JDK 9.
>>> 
>>> Interesting talk !
>>> 
>>> to get back to our issue,
>>> there are 4 possibilities when exporting a package, for a public type,
>>> (1) don't see it at compile time, don't see it at runtime (can't reflect on it)
>>> (2) don't see it at compile time, see it at runtime (this is the OSGI/JBoss
>>> model for not exported)
>>> (3) see it at compile time, may not exist at runtime (so be prepared to get an
>>> exception then)
>>> (4) see it at compile time and see it at runtime
>>> 
>>> The default can not be (3) because it's a corner case, it can not be (4) because
>>> in that case we lost the 'strong encapsulation' that a module should provide by
>>> default, so the default can be either (1), either (2) or to force the user to
>>> choose between (1) and (2) when declaring a module.
>>> 
>>> The problem with (1) is that:
>>> - it makes most of the code that use reflection not working (and as Stephen
>>> said, at lot of codes use reflection (or bytecode generation)),
>>> - it will slow down the adoption of jigsaw (not jdk9 which will be run with a
>>> -classpth) but the modularization of the already existing jars, so we will end
>>> up with a module system which will be not used or worst, some jars will be
>>> modularized, some will not and we will be in the same sad state of Python now
>>> with 2 mostly compatible worlds *.
>>> 
>>> The problem of letting users to choose is that the hope to educate them by
>>> forcing them to make their own choices will be destroyed because in practice
>>> IDEs will chose for them (e.printStackTrace() anyone ?)
>>> 
>>> So the only valid choice seem to be (2), which
>>> - still enable JDK and application server implementation modules to not export
>>> some types at runtime, so the security will improve and by example, it will
>>> avoid most of the access control bugs Christina talk about.
>>> - the default behavior will make the move to convert their jars to modularized
>>> jars easier because people will not conflate the problem of the modularization
>>> itself with the problem of the access control at runtime.
>>> - everybody will be happy and we will not see angry ponies on slides about Java
>>> 9.
>> 
>> This is all rearranging deck chairs.  The critical problem here, lest we forget,
>> is that none of these solutions allow reflection to work on modules without an
>> export, even for public types, thus breaking *everything* eventually.  Any
>> valid choice IMO must allow public types to remain public and thus globally
>> accessible.
>> 
>> Since everyone seems to concede that the migration to any more secure form for
>> users must be incremental, there is nothing left to be gained by the existing
>> Jigsaw public access restriction.  After all, even if public is left as public,
>> it is still possible meet any reasonable standard of encapsulation.  That
>> aforementioned incremental migration could be for users and JDK developers to
>> change public classes to be non-public; the mechanism which currently allows
>> for exporting packages to modules is conceptually *very* close to a mechanism
>> to share the non-public classes in packages with modules.
>> 
>> In other words, users should be able to export packages with a module target or
>> a wildcard (which allows compile-time and run-time linkage to connect to those
>> packages), and also specify whether each (non-wildcard) export should include
>> access to private types (which allows that linkage to connect types to those
>> non-public members).
>> 
>> In addition to my aforementioned --safe-mode idea, I think it could also be
>> possible/easy to provide a facility for modules to be marked such that using
>> setAccessible from that module would be disallowed.
>> 
>> Would this not solve every problem and use case raised thus far, as well as
>> being far more intuitive for users?
>> --
> > - DML