[rfc][icedtea-web] DeploymentPropertiesAreExposed reproducer fix

[Omair Majid]

Hi Jacob,

I wanted to avoid doing these explanations so I pointed you to the spec.
Looks like I did not clarify what I meant, so let me try again :)

On 09/16/2013 08:26 PM, Jacob Wisor wrote:
> This suggests that there had been an attempt or had been thought about
> filtering out classes in /restricted/ packages, but this does not seem
> to be in effect anymore or not yet.

This is restricted by two things:

1. The existing java.security file shipped with your (open)JDK. This
should define a variable called package.access. This variable contains
packages that can not be accessed without a permission check. Untrusted
code accessing a package (any package) will trigger a permission check -
this is done in the JDK and not in icedtea-web.

2. IcedTea-Web adds itself to this list on startup.

This takes care of untrusted applications trying to access
net.sourceforge.jnlp.*.

> Furthermore, I also did not find any text in the specifications nor the
> reference documentation that would support the claim that class loaders
> define separate class or namespace domains.

It doesn't. But please read my mail again because that's not the claim I
made. I only mentioned making fields package-private. And the JVM spec
does clarify that:

"""
5.4.4 Access control:

A field or method R is accessible to a class or interface D if and only
if any of the following conditions are true:

(snip)

    R is either protected or has default access (that is, neither public
nor protected nor private), and is declared by a class in the same
run-time package as D.
"""

Given that our net.sourceforge.jnlp* classes are a in different run-time
package than an attacker supplied net.sourceforge.jnlp.* class, making
things package-private limits access.

Cheers,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681