Security
Tim Ellison
Tim_Ellison at uk.ibm.com
Tue Mar 10 14:55:40 UTC 2015
"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
More information about the jpms-spec-observers
mailing list