Security

[mark.reinhold at oracle.com]

2015/2/20 1:48 -0800, david.lloyd at redhat.com:
> On 02/16/2015 11:04 AM, Tim Ellison wrote:
>> ...
>> 
>> 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>.  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.
> 
> In JBoss Modules, we did this very thing, with a simple per-module 
> protection domain concept where the permissions are actually established 
> within the module description itself.  ...
> 
> I think there is definitely value in the module knowing what permissions 
> it needs to function, and to be shipped with those permissions.  I think 
> that if this is combined with a configuration-specific verification 
> mechanism, this could allow users to express a level of trust the way 
> they do today for signed JARs, and/or perhaps be able to verify (at 
> install time) whether or not they want to go ahead with installing a 
> module with certain permissions.

I can imagine building something like this, but would anyone use it?

I've seen little evidence over the years of broad use of the fine-grained
security model introduced way back in JDK 1.2.  Do we really need to
complicate the module system with permission declarations?

- Mark