Not using signers in JNLPPolicy.getPermissions()

[Omair Majid]

On 01/04/2011 04:42 PM, Deepak Bhole wrote:
> * Omair Majid<omajid at redhat.com>  [2011-01-04 16:33]:
>> On 01/04/2011 04:05 PM, Deepak Bhole wrote:
>>> * Omair Majid<omajid at redhat.com>   [2010-12-17 18:07]:
>>>> Hi,
>>>>
>>>> I noticed this line in JNLPPolicy.getPermissions(CodeSource source):
>>>>
>>>> CodeSource appletCS = new CodeSource(JNLPRuntime.getApplication().getJNLPFile().getSourceLocation(),
>>>> (java.security.cert.Certificate[]) null);
>>>>
>>>> I understand that we need a URL to the actual source of the code
>>>> (instead of a url to the on-disk cache), but why use null as the
>>>> certificate array? Is there a reason we are not using the actual
>>>> signers associated with the CodeSource?
>>>>
>>>
>>> appletCS is used only in the getPermissions call below, whose return is
>>> merged with the permissions that the jar code signer has
>>> (clPermissions).
>>>
>>> clPermissions already accounts for code-signer specific permissions, so
>>> providing signers to the CodeSource constructor would make no
>>> difference, and was probably done to avoid redundant merging.
>>>
>>
>> Thanks for the explanation. However, I still dont think this code is
>> entirely correct. clPermissions (as far as I can tell) does not
>> account for system policy. If the system's policy file contains
>> something like:
>>
>> grant signedBy "Duke" {
>>      permission java.io.FilePermission "/tmp/*", "read,write";
>> };
>>
>> And the applet is signed by Duke, the code wont be granted these
>> permissions (but like other signed code, it will be granted
>> AllPermissions - unless a policy file is used to grant it a subset
>> of permissions rather than all permissions).
>>
>
> Ah, sorry, you are correct. I thought there was another getPermissions
> call based on signer in JNLPClassLoader, but that is not that case.
> That said however, AllPermission trumps per-cert permissions anyway, and
> that is the expected behaviour. The docs state:
>
> "With this (deployment.security.trusted.policy) property unset
> (default), trusted code will be granted the AllPermission permission."
>

Oh, yes. I agree that this should not be a problem in the default 
configuration.

> I am trying to understand what would be gained by providing code signers
> to the CodeSource constructor.. or am I missing something?
>

Well, as the documentation says, AllPermissions are not granted if 
deployment.security.trusted.policy points to a policy file. So suppose 
an advanced user sets up a policy file to grant no permissions to 
trusted code. The user then adds a custom policy rule (in the system 
policy file or the deployment-specific policy file) to grant 
AllPermissions to code signed by a signer "Foo". Now an applet signed by 
"Bar" will (or should!) run in a sandbox. However, an applet signed by 
"Foo" should run with all permissions, but because the code signer is 
null, it will be granted no permissions and it will run in a sandbox.

Thanks,
Omair