Security
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Mon Mar 9 21:02:18 UTC 2015
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
More information about the jpms-spec-observers
mailing list