Security

[mark.reinhold at oracle.com]

2015/3/17 7:34 -0700, david.lloyd at redhat.com:
> On 03/16/2015 03:50 PM, mark.reinhold at oracle.com wrote:
>> 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.

Here's a new requirement to capture that:

  - _Protection domains (NEW)_ --- At run time it must be possible to
    associate the code in modules with protection domains, for the
    purpose of granting security permissions.

- Mark