Security

[mark.reinhold at oracle.com]

2015/3/10 6:37 -0700, david.lloyd at redhat.com:
> On 3/9/15 4:02 PM, mark.reinhold at oracle.com wrote:
>> 2015/2/20 1:48 -0800, david.lloyd at redhat.com:
>>> ...
>>> 
>>> 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.

(See my other reply, nearby, on permissions in EE.)

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

Would we find that people are granting permissions to specific JAR files
and/or code signers, or would we find that they're using coarser-grained
mechanisms (the Applet/JNLP sandbox, EE's permissions.xml, etc.)?

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

Sorry, but in general this kind of reasoning is not persuasive.  Many
features were included in early versions of Java because they were simple
to implement and there weren't compelling reasons not to include them,
yet in hindsight we regret having added them.

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

Isn't that better handled by whatever mechanism is used to install Java
modules on the local system (e.g., RPM)?

- Mark