Security

[David M. Lloyd]

On 3/9/15 4:02 PM, mark.reinhold at oracle.com wrote:
> 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?

We've seen a reasonably significant usage of security managers and their 
associated permissions, especially now that it is a part of Java EE, so 
the functionality would at least need to be present to bring Java EE 
forward into this world.

The fact is that many environments (corporate, educational, government) 
require the use of a security manager for their Java based applications; 
it is my belief that if we each reached out to our associated support 
organizations, we'd find that this is generally true.

Without a convenient way to establish permissions per module, it's 
really a step backwards in this area, and (at least at present) it is so 
simple to implement that there doesn't seem to be a compelling argument 
*not* to do it.

And I suspect that whether or not we provide a mechanism for 
distributors to assign permissions to modules, there still needs to be 
some kind of trust decision by the installer to decide whether (s)he 
wants to install the module in question based on where it comes from.

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

I think we really should.

-- 
- DML