Security (was: Re: Module-system requirements)

[mark.reinhold at oracle.com]

2015/2/16 9:04 -0800, tim_ellison at uk.ibm.com:
> Presently, JAR files fulfil a number of different roles, including being 
> one of the structured container types for resources.  As modules are 
> introduced there is an opportunity to use this artifact for some security 
> concepts that are container-based.  For example, while it may be implied 
> by the 'Non-interference' requirement, it may be desirable to consider 
> modules to be sealed, thereby guaranteeing that all classes in a package 
> come from the same module.

I think that is implied by the non-interference requirement, but just to
make it clear:

  - _Non-interference_ --- The Java compiler, virtual machine, and
    run-time system must ensure that modules that contain packages of the
    same name do not interfere with each other.  If two distinct modules
    contain packages of the same name then, from the perspective of each
    module, all of the types and members in that package are defined only
    by that module.  Code in that package in one module must not be able
    to access package-private types or members in that package in the
    other module.

> I was going to suggest that modules be considered a CodeSource so that 
> they can be signed, or form a protection domain with a configurable 
> security policy, without consideration for their (file system) container - 
> but I may have talked myself out of it <g>.

(I'll assume that by "container" here you mean "artifact" rather than,
 say, a "container-style" application such as an IDE or an app server.)

>                                              Perhaps these concepts should 
> remain with the container, notwithstanding the fact that a linked custom 
> binary run-time image may well collapse the containers and invalidate any 
> signing/policies associated with the originals.

Yes, I suspect these concepts should remain container/artifact-specific,
except possibly for signing, but I think we can leave this as a design
decision to be worked out later.

> A security algorithm implementation provider may always have to be part of 
> a separate verifiable container to maintain the current level of 
> integrity.

Yes.

- Mark