Security

[mark.reinhold at oracle.com]

2015/3/10 8:40 -0700, david.lloyd at redhat.com:
> On 3/10/15 9:55 AM, Tim Ellison wrote:
>> ...
>> 
>> David, is it not sufficient that the java.policy file can contain a
>> code source url specifying jrt:/$MODULE ?  This gives a mechanism for
>> permissions to be granted to code associated with a module
>> irrespective of the artifact that delivers the module.
> 
> I believe not, for these reasons:
> 
> • The policy file is not AFAIK actually standardized in the SE platform, 
> though (of course) the policy mechanism itself is.

Correct.

> • The "jrt" URL scheme, as I understand it, applies specifically to the 
> JDK runtime and not generally to modules.

The "jrt" scheme can be used to name any module linked statically into
the run-time image, whether an SE/JDK module or a library or application
module.  It cannot be used to name modules loaded at run time, so from a
security perspective (where URLs are needed) it's not a general solution
to the module-naming problem.

> • The JDK runtime itself effectively has AllPermission as far as I 
> understand.

No, the permissions granted to code not loaded by the bootstrap class
loader are limited.  Have a look at the JDK 9 default java.policy file:

  http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.base/share/conf/security/java.policy

(This does, however, seem like a side issue.)

> • Assuming that each configuration (I guess?) gets a unique URL scheme 
> which applies to it,

I don't think each configuration (= set of resolved modules) would get
its own URL scheme, or even a URL.  I could imagine each module in a
system, whether statically linked or dynamically loaded, having a unique
URL, but it's yet not clear to me whether that's needed.

>                      using the global policy exclusively is still 
> non-optimal because it loses a substantial amount of information: the 
> author of the module knows what permissions the module would require, 
> whereas the consumer of the module does not have this knowledge.

Is this really true, in general?  If I ship, say, a JDBC driver then I
won't know ahead of time which network hosts and ports it will need to
access -- that's up to the application that uses it.

>                                                                   The 
> consumer would on the other hand want the ability to define a governing 
> or maximal set of permissions, either globally, per-configuration, or 
> per-module, which could well be done by policy (or not).  Adding in some 
> kind of interactive process for verifying installation of modules which 
> would violate this maximal constraint falls more under the "gravy" 
> category in my mind.

I think that kind of functionality is up to specific products to provide;
it's well beyond the scope of a module system.

> • Also I think I'll just keep repeating "Java EE 7" over and over again. 
> :-)  We likely need, at a minimum, the ability to programmatically 
> define modules with specific permission sets to be able to support EE.

Let's dig into this.

The EE 7 specification defines a way (§6.2.2.6) to grant permissions to
the classes inside an EE "module" -- an artifact, really, i.e., an EAR,
WAR, or RAR file -- using the META-INF/permissions.xml resource.

What would it mean to support this model in a modular environment?  That
depends on exactly how a future version of the EE specification adopts
the module system.  Based on conversations with the EE spec leads, I
strongly suspect that it will allow code that's today packaged in JAR
files inside EE artifacts (EAR/WAR/RAR) to instead be packaged as
modules.  I doubt it will involve replacing EAR/WAR/RAR files themselves
with modules, so permissions.xml (or its successors) will remain the
standard way to grant permissions to code inside EE artifacts.

Does this mean that we need a way to grant permissions to specific
modules, i.e., do we need to be able to treat modules as code sources?

No, I don't think so.  Modules will be embedded within an EE artifact,
which may have its own permissions.xml file, which grants permissions to
all code loaded from the artifact.  If we assume that each artifact is
loaded by a specific set of class loaders (maybe one, maybe many), then
the protection domains can be set up based on class loaders (only) and
there's no need to grant permissions on a per-module basis.

>> I don't see any mention of the ability to sign a module, but provided
>> there is an extensible metadata space (equivalent to the META-INF
>> directory) associated with a module, then I think we are good for that
>> too, no?
> 
> I'm not sure.  Signing is definitely a distribution/installation concern 
> though, far more than a run time concern in my opinion.

I tend to agree.  The Java security architecture can grant fine-grained
permissions based upon the signers of a code source, but I don't think
this ability is widely used.

- Mark