Security

[mark.reinhold at oracle.com]

2015/9/17 8:34 -0700, david.lloyd at redhat.com:
> On 09/17/2015 09:56 AM, mark.reinhold at oracle.com wrote:
>> 2015/9/11 10:15 -0700, forax at univ-mlv.fr:
>>> While this change may improve the security, it's a
>>> backward incompatible change is not strictly required to support
>>> modules it's more an enhancement of the current security model and i
>>> don't think it's a good idea to mix it with the introduction of the
>>> module support.
>> 
>> This is not an enhancement of the security model per se (which would,
>> anyway, be beyond the scope of this JSR).  This change is, rather, in
>> service of the strong-encapsulation goal (which does, of course, help
>> ensure security).
> 
> I think this assertion should be substantiated with some examples.
> 
> While strong encapsulation is good in terms of design principles, to me 
> it's only evident that this somehow leads to better security in the most 
> hand-wavy possible way (in particular, as it relates to this specific 
> mechanism).

Three of the five zero-day vulnerabilities reported since JDK 7 GA would
have been prevented if we'd had the ability to strongly encapsulate
JDK-internal packages in the manner proposed, via access-control checks
enforced by the VM.

Here are public analyses of two of them:

  https://partners.immunityinc.com/idocs/Java%20MBeanInstantiator.findClass%200day%20Analysis.pdf
  http://immunityproducts.blogspot.com/2012/08/java-0day-analysis-cve-2012-4681.html

The lead of Oracle's Java Vulnerability Team estimates that at least a
third of all the vulnerabilities reported since JDK 7 GA would have been
prevented if we'd had the ability to strongly encapsulate JDK-internal
packages.

>              On the other hand, there is strong evidence to support the 
> assertion that enhancing the security model in any way immediately leads 
> to new CVEs.  The more behavioral rules there are in place, the more 
> vectors for exploitation will appear.

In the abstract, I agree with you.  The proposed means of encapsulation,
however, does not depend upon the existing complex security architecture,
so it should be easier to validate.

> ...
> 
>> To truly support strong encapsulation would require taking setAccessible
>> away completely.  I think that's desirable in the (very) long term, but
>> it would break too much existing code in the near term.
> 
> I don't agree that this is true.  Encapsulation is really a social 
> construct; while accessibility can be used to create and enforce 
> encapsulation-justified rules, it doesn't *have* to.  You do need some 
> kind of back door, no matter what, or else you severely limit the power 
> and capability of the platform (as evidenced by the widespread usage of 
> the reflection back door by many widely-used frameworks generally 
> considered to be powerful and capable).
> 
> If encapsulation as a design principle is the goal, then simple 
> isolation rules between modules (as between unrelated class loaders) has 
> already been proven to be highly effective.

If all you mean by "encapsulation" is a social construct then sure, none
of this would be necessary.  That's insufficient, however, in the face
of actual security threats.  Aside from security considerations, a social
contract implies a level of understanding and trust that is difficult,
if not impossible, to achieve in a broad community of millions of
developers.

>                                              The relationship between 
> this new encapsulation rule and security, on the other hand, has yet to 
> be shown.

(See above.)

> In this light, I don't see how these changes cannot be considered a 
> modification of the security model just because they ride in on the 
> coattails of a new abstraction.

It depends upon what you mean by "security model".

If you mean some high-level, abstract view of all the various mechanisms
in the language, VM, and libraries that help ensure security then yes,
the proposed changes are an extension of that model.

When I write "security model", however, I usually mean the subsystem
which evolved from the simple (and simplistic) java.lang.SecurityManager
API in Java 1.0 to the complex policy/permission-based architecture of
the 1.2 release.  Many run-time operations (in class loaders, reflection,
I/O, etc.) are subject to checks done by the security subsystem, and if
just one of those checks is missing or incorrect then it may well be
"game over".

The proposed enforcement of module boundaries via access restrictions
expressed in the language, recorded in class files, and enforced by the
compiler and the VM do not in any way depend upon that subsystem, nor do
they extend it.  The VM will never upcall into the security subsystem in
order to determine whether one type is permitted to access another.  The
implementation of access-control checks in a JVM is typically highly
localized and much easier to validate than the comparatively large body
of code in the (mostly) Java-level security subsystem.

>> ...
>> 
>>                                       ...  If encapsulation is to mean
>> anything then it should not be possible to break it solely from within
>> the language itself.  Enabling such powers via an external, second-class
>> mechanism such as a command-line option or a debugger is fine, but the
>> history of Java has shown that if it's easy to break encapsulation then
>> people will do so, increasing everyone's maintenance burdens over the
>> long haul.
> 
> I think this may be a somewhat narrow view.  People break encapsulation 
> when they need a capability that cannot be provided another way.  Now 
> the JDK, unfortunately, historically contains very many "goodies" and 
> bits of useful functionality that users want access to, so it is a 
> disproportionately popular target for such breakage, but apart from 
> accessing JDK internals, I believe that the use cases for breaking in 
> through the security model are legitimate and should be allowed to 
> adequately privileged code.

How do you identify "adequately privileged code"?  (This is an open issue
we need to address.)

>                              Using an appropriate security model, it is 
> not difficult to ensure that such powers are not exploited (though while 
> in practice it is more difficult due to a variety of factors, I do not 
> believe those factors are directly related to this mechanism but rather 
> to exceptions, special "holes", and other technical debt that exists in 
> the JDK itself for historical or other reasons).

I don't think that the future of the platform would be well-served by a
model that works well only for code outside of the JDK, if that's what
you mean.

- Mark