Security

[Tim Ellison]

"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 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'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 ;-/ !?  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.

Regards,
Tim


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU