Security

[David M. Lloyd]

On 03/16/2015 03:50 PM, mark.reinhold at oracle.com wrote:
> 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.

Indeed I maintain that each module loading configuration should have 
control over module naming and assignment of code source and URL scheme, 
as different systems have different requirements.  I don't think that 
"jrt" *must* resolve libraries and application modules, but it certainly 
*could*; OTOH that job could also be done by another layer.

For example I could have my container define a 
"deployment:/myapp.ear/helloworld.war" kind of URL scheme for modules 
which correspond to deployments.  I could use a URN like 
"ext:my-extension" to map to legacy extensions, and so on.  Each scheme 
would have a different mapping strategy, and each module configuration 
may indeed have different naming constraints or rules.

>> • 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.)

I should have said "the bootstrap class loader portion of the JDK...". 
But yes this is a side issue for sure.

>> • 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.

Another side discussion I guess.

>>                       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.

True; but the JDBC driver author would definitely know that it needs to 
be able to access *some* hosts and ports.  It would define the broad 
permission to do so, subject to the consumer's narrowing if they do not 
trust that code with that privilege for some reason (for example perhaps 
it is buggy or tries to connect to some other undesired service or 
something like that).

>>                                                                    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.

Sure, it just illustrates the point that the use cases behind the 
requirements in EE7.6.2.2 which allow the module to define permissions 
and the container to restrict or enhance them are legitimate and useful, 
so they should at least be *possible* to implement within the module 
system.  If the module system were to prevent any setting of permission 
other than the Policy, that would be very unfortunate.

>> • 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 think that treating modules as code sources is necessarily the 
conclusion to draw here.  Since JBoss Modules has a high correspondence 
between artifacts and modules, assigning permissions to modules is easy 
and convenient, and they inherit automatically to their constituent code 
sources.  But even if the ability were defined in terms of establishing 
permissions on the code sources directly, that would suffice as well 
since the former could always be implemented in terms of the latter. 
Requiring the global Policy to get involved is mostly just useless 
overhead though, and forces coordination between all module loading 
parties that want to be able to define permissions.

I'd settle for allowing the definition of ProtectionDomains to be 
customized as they can be today though.

>>> 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.

I agree, most of the time it seems that the code source URL is used by 
itself in security policies.

-- 
- DML