White-listing sensitive linker targets

Mike Samuel mikesamuel at gmail.com
Thu Jun 2 17:22:31 UTC 2016


Alex Buckley said

> It appears that Sally is exporting org.example.unsafe to everyone, such
> that Aaron can refer to that package in his code and compile locally.
> Happily, the build system detects his module isn't on the white-list
> (Sally's approved third party libraries) and refuses to "validate" his
> module.

> Since the white-list is known statically, Sally's module should reify it
> via qualified exports:

>    exports org.example.unsafe to ApprovedMod1, ApprovedMod2, ...;

> Then, Aaron's code which refers to org.example.unsafe.* will not
> compile. Even if he obtains a Class object for org.example.unsafe.Foo,
> he will find that newInstance() fails. Even if he obtains Field and
> Method objects for Foo's members, he will find that get()/set()/invoke()
> fail. setAccessible() will not help him. It doesn't matter that static
> analysis can't detect these attempts to access white-listed module
> content, because the module system will dynamically prevent them.

Thanks for explaining.  That helped a lot and it's great to hear about
the restrictions on get()/set()/invoke().

It sounds like the tech lead, specialists, and build master can
exercise oversight using tools that just

1. look at the exports...to... relationships which should be apparent
from module declarations in bytecode per
http://openjdk.java.net/projects/jigsaw/spec/sotms/#qualified-exports
2. check that sensitive packages are only contained in modules defined
in build artifacts signed by the right group.

What about JSR 223 style script engines?
Can an embedder of an interpreter or bytecode compiler create a module
that includes the scripting engine and just the stuff that the scripts
need and be sure that, whether the script engine uses reflection under
the hood, or compiles to bytecode?  Or does all that stuff tend to end
up in the unnamed module?

cheers,
mike


More information about the jigsaw-dev mailing list