[icedtea-web] (PR1513) Signed JAR with external main-class

[Andrew Azores]

On 10/29/2013 02:09 PM, Omair Majid wrote:
> * Andrew Azores <aazores at redhat.com> [2013-10-23 16:36]:
>> Fix and reproducer patches attached. The fix is a little bit of an
>> ugly workaround I guess, but I think a nicer solution would involve
>> rewriting a lot of other things. Maybe that can come later on down
>> the road.
>>
>> What happens here is that if the JNLPFile's main-class is marked as
>> external by the JNLPClassLoader, then the AppVerifiers will never
>> use AccessType.VERIFIED. Instead, either SIGNING_ERROR or UNVERIFIED
>> will be used. Which one depends on
>> CertInformation#isRootInCaCerts(). If this returns true then you get
>> the "signing error" dialog box, else you get the "unverified"
>> message. The classloader still considers the applet to be signed,
>> however. I figured it was better to tell the user there's a signing
>> trust issue and ask for confirmation to run with full permissions,
>> rather than restricting the applet to sandbox permissions, since the
>> signed portion of the applet could very well require more
>> permissions than that.
> I am still concerned that we will load other classes from the code base
> without warning, but will only warn about main class. I dont know if the
> main class is special enough to make this distinction, if this can
> happen with other classes too.
>
> I would be okay with handling the main class and ignoring others (if
> that even happens), but since the patch is a bit of a hack, I want to be
> sure of this.
>
> Thanks,
> Omair

If the main-class is outside of the JAR then the user is given a general 
warning message about the applet having a signing error, with no mention 
of which class(es) are unsigned and causing this message to appear. If 
we're allowing any unsigned code to run at all (with user approval) then 
I don't think it matters too much if that code is marked as the 
main-class or not. Either way it's unverified code being run as part of 
a signed, all-permissions-granted applet, so the user just needs to know 
that this is definitely risky.

If the main-class is within a signed JAR, as it should be, but the 
applet tries to load loose classes from the codebase - well, it would 
definitely be a problem if we allowed those unverified classes to be 
executed with signed privileges. I don't think we are doing that now, 
and I don't think this patch would introduce that problem, since signed 
applets with the main-class within a JAR are not really affected by this 
change.

I've attached another patch which does the job and is easier to reason 
about. I think I prefer the dialog presented by the last patch, as 
there's only one dialog that appears in that one - this patch causes 
there to be two, and they might be a little confusing to see in 
succession. See the applet at [1] with either patch applied to see the 
difference. As well, marking the main-class as external as in the older 
patch might be useful in the future for other purposes. But at least for 
fixing the particular bug report which caused this investigation, I 
think this new patch is sufficient and importantly, easier to verify as 
not introducing any issues with loading unverified classes. If we have 
any problems like that, they are pre-existing and can be addressed 
separately from this changeset IMHO.

Also the reproducers added last time require intervention to approve and 
run with this new patch as the other dialog box still appears even if 
you have security set to never prompt. Which, really, might be something 
else to look into changing.

[1] https://oasisweb.uga.edu/oasis.html

Thanks,

-- 
Andrew A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signed-applet-external-main-class-simplefix.patch
Type: text/x-patch
Size: 2618 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20131029/753572b0/signed-applet-external-main-class-simplefix.patch