Security (was: Re: Module-system requirements)

[Tim Ellison]

mark.reinhold at oracle.com wrote on 16/02/2015 01:25:07:
> 2015/2/13 6:06 -0800, tim_ellison at uk.ibm.com:
> > <snip>
> >  - It would be useful to have a section on Security.  While there are 
> > aspects throughout other sections of the requirements, such as 
> > encapsulation and referential integrity, there may be other 
considerations 
> > where module boundaries can be used to enhance security, e.g. only 
> > allowing privilege escalation within a module scope, modules declaring 
all 
> > exported APIs fail when passed a tainted string, etc.  I'm not 
proposing 
> > scope-creep but rather ensuring folks have had the chance to think 
about 
> > it and easy opportunities are not missed to make Java 9 even more 
secure.
> 
> I'm all for improving security (obviously!), but if I've learned one
> thing about that general topic over the years it's that it's more a
> state of mind, or a way of life, than a set of features.  It runs
> through everything that we do.
> 
> Putting every requirement that's somehow related to security into a
> special "security" section of this document would just make it harder to
> read, and I'm skeptical that it'd actually make us all think even more
> about security than we already do.  If you'd like to propose additional
> security-related requirements then by all means please go ahead, and
> we'll see where they fit into the present structure.

Presently, JAR files fulfil a number of different roles, including being 
one of the structured container types for resources.  As modules are 
introduced there is an opportunity to use this artifact for some security 
concepts that are container-based.  For example, while it may be implied 
by the 'Non-interference' requirement, it may be desirable to consider 
modules to be sealed, thereby guaranteeing that all classes in a package 
come from the same module.

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.

A security algorithm implementation provider may always have to be part of 
a separate verifiable container to maintain the current level of 
integrity.

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