Security

[David M. Lloyd]

On 02/16/2015 11:04 AM, Tim Ellison wrote:
> 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.

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.  This dovetails nicely into Java 
EE 7 permission specifications, since we can use the same description 
API to assign those permissions, where the container configuration 
defines minimal and maximal permission sets that the deployment 
permissions are matched against.  Other ideas I considered experimenting 
with were per-code-source permissions (since a JBoss Module can 
aggregate more than one resource root) as well as per-class/package 
permissions (maybe via annotations).

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.

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

Agreed.
-- 
- DML