White-listing sensitive linker targets

[Mike Samuel]

On Thu, Jun 2, 2016 at 3:37 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> On 6/2/2016 10:22 AM, Mike Samuel wrote:
>>
>> 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
>
>
> Yes, the qualified exports should drive everything, since they're
> bulletproof. (A module can choose to augment its own exports at run time,
> but hopefully the overseers recognize that more as a "feature" for Sally to
> use judiciously than as a "bug" which weakens the authority of the static
> white-list.)

I agree re "judicious."

One of my goals is to encourage architectures that allow auditors to
prioritize so that,
for a particular security property, most of the code requires only
cursory review.

It's difficult to keep tight bounds on a secure kernel when review is happening
concurrently with development unless you can compute that kernel statically and
see that it is more or less stable.



>> 2. check that sensitive packages are only contained in modules defined
>> in build artifacts signed by the right group.
>
>
> Yes, this is a job for the build system. The placement of packages in
> modules is something that the module system has to take on trust.

Understood.


>> 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?
>
>
> The way that frameworks use the module system is a deep topic, but
> ultimately a JSR-223 ScriptEngineFactory is just a service provider, so you
> can create a module which 'provides' a class implementing
> ScriptEngineFactory and which 'requires' java.scripting + the other modules
> it needs. The module can't access anything which isn't exported to it,
> regardless of whether the access is from bytecode or via Core Reflection or
> via the Language Model or via MethodHandle lookup.

Great.   So this can serve as a defense-in-depth with but not a replacement for
interpreter sandboxing.
The base module contains java.io so modularity can't, by itself,
prevent a crafted script
from using ObjectInputStream to forge objects by deserializing crafted
byte strings,
but the script would need to have access to the class of the object
it's trying to forge via
the module system.