[rfc][icedtea-web] DeploymentPropertiesAreExposed reproducer fix

[Jacob Wisor]

Hello Omair,

Omair Majid wrote:
> 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.*.

Yes, I have done some testing (even with some less naive test than Jiri's) 
myself and have come to the same conclusion after examining the exception stack 
trace, namely that IcedTea-Web does add the net.sourceforge.jnlp.* package 
namespace to the list of restricted packages with its own JNLPSecurityManager. 
You are right, it does take care of malicious code that may put its classes into 
net.sourceforge.jnlp. Now I am feeling uncomfortable with IcedTea-Web 
restricting access to the net.sourceforge.jnlp package namespace entirely 
because this package namespace is not reserved by any public specification. 
Although this probably does not pose a problem in practice, I am thinking 
whether IcedTea-Web should not take a more granular approach when restricting 
access. Should not it only restrict access to actually existing IcedTea-Web classes?

And, since signed jars get AllPermissions by default it is still advised to keep 
access to fields and methods as limited as possible but as open as necessary.

>> 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.

Well, then obviously class loaders do define separate namespace domains 
effectively, at least at run-time. This is a hell of a way to describe it. :-D 
The JVM spec brings up the distinct concepts of run-time packages and 
compile-time packages rather in passing. I would have expected this concept to 
be described in a separate paragraph.

Nevertheless, the fields of concern in net.sourceforge.jnlp.config.Defaults 
should still be kept to default access modifiers. The reproducer can load javaws 
with the system class loader that has an AllPermissions security context. 
Because of that it can also load its helper class in net.sourceforge.jnlp.config 
into javaws' net.sourceforge.jnlp.config run-time package by using 
JNLPClassLoader providing its AllPermissions security context. Then the 
reproducer should be able to access the fields in question via its helper class.

Regards,
Jacob