Security

[David M. Lloyd]

On 3/10/15 9:55 AM, Tim Ellison wrote:
> "jpms-spec-experts" <jpms-spec-experts-bounces at openjdk.java.net> wrote on
> 10/03/2015 13:37:52:
>> 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.
>
> David, is it not sufficient that the java.policy file can contain a code
> source url specifying jrt:/$MODULE ?  This gives a mechanism for
> permissions
> to be granted to code associated with a module irrespective of the
> artifact
> that delivers the module.

I believe not, for these reasons:

• The policy file is not AFAIK actually standardized in the SE platform, 
though (of course) the policy mechanism itself is.
• The "jrt" URL scheme, as I understand it, applies specifically to the 
JDK runtime and not generally to modules.
• The JDK runtime itself effectively has AllPermission as far as I 
understand.
• Assuming that each configuration (I guess?) gets a unique URL scheme 
which applies to it, using the global policy exclusively is still 
non-optimal because it loses a substantial amount of information: the 
author of the module knows what permissions the module would require, 
whereas the consumer of the module does not have this knowledge.  The 
consumer would on the other hand want the ability to define a governing 
or maximal set of permissions, either globally, per-configuration, or 
per-module, which could well be done by policy (or not).  Adding in some 
kind of interactive process for verifying installation of modules which 
would violate this maximal constraint falls more under the "gravy" 
category in my mind.
• Also I think I'll just keep repeating "Java EE 7" over and over again. 
:-)  We likely need, at a minimum, the ability to programmatically 
define modules with specific permission sets to be able to support EE.

> I don't see any mention of the ability to sign a module, but provided
> there
> is an extensible metadata space (equivalent to the META-INF directory)
> associated with a module, then I think we are good for that too, no?

I'm not sure.  Signing is definitely a distribution/installation concern 
though, far more than a run time concern in my opinion.

>>> 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.
>
> Should complicate it ;-/ !?

Yes, I deliberately disregarded the prejudicial language, but addressing 
it head-on, I firmly believe we are not talking about something that is 
substantially complex here, so "complicate" is probably far too strong a 
term.

> I agree that a mechanism for continuing the
> 'somewhat less than optimal' security model is better than ignoring it.
> Better yet to use this as an opportunity to improve the code security
> model,
> though I see that as beyond the scope of the modularity JSR.

I agree, I would love to see improvements in this area.  I also agree 
it's probably out of scope, unless some surprisingly low-hanging fruit 
would appear.

-- 
- DML