[RFC][IcedTea-Web]: Change #4 (PersistenceService) of new JNLP specification (v7.0)

[Deepak Bhole]

* Omair Majid <omajid at redhat.com> [2011-06-08 17:01]:
> On 06/08/2011 04:54 PM, Deepak Bhole wrote:
> >* Omair Majid<omajid at redhat.com>  [2011-06-08 16:46]:
> >>On 06/08/2011 04:19 PM, Saad Mohammad wrote:
> >>>On 06/08/2011 03:52 PM, Omair Majid wrote:
> >>>>app = JNLPRuntime.getApplication();
> >>>I am looking into ApplicationInstance.isSigned at the moment, and I will
> >>>try running some test to see if it is actually a better method to
> >>>determine whether the application has a signature.
> >>
> >>Please do NOT use ApplicationIsntance.isSigned(). Deepak himself
> >>patched checkAccess to avoid using ApplicationInstance.isSigned. It
> >>is not enough. You can have unsigned applications calling privileged
> >>code which does doPrivileged() operations. I think it's completely
> >>fine to allow them to use PersistenceService.
> >>
> >
> >I can't recall why I made the change, but I thought it was due to the
> >case of it being called from JNLPSecurityManager.
> >
> >What do you mean by unsigned apps calling doPrivileged() operations? Can
> >you give an example where that would lead to app being null?
> >
> 
> Sure. I am not worried about app being null though. It wont be.
> 
> Supposed a privileged application A uses an extension jnlp B. A is
> signed/trusted but B isnt. When using isSigned(), code from B will
> be able to access persistence service information from any
> application. Even though code from B is unsigned/untrusted.
> 
> Similarly, suppose an unprivileged application C uses a signed jnlp
> extension D. If we use isSigned() then D, even in a doPrivileged()
> block, will not be able to access the persistence cache for any url.
> Given that D is signed/trusted, it should be able to do anything -
> it can certainly access the persistence store using java.io.File
> directly.
> 

Ah, I see what you mean now. Yes, you are correct, isSigned is
insufficient in this case and we do need a separate method that checks
the stack.

Sorry for the initial noise :/

Cheers,
Deepak

> I think it's best to look at the current stack, and use the
> permissions there to make a security decision about whether the code
> on the stack is trusted or not - and whether it should be able to
> access persistence service information for any url or not.
> 
> What do you think?
> 
> Cheers,
> Omair