[rfc][icedtea-web] Temporary permissions

[Andrew Azores]

On 03/24/2014 12:18 PM, Jiri Vanek wrote:
> On 03/24/2014 04:55 PM, Andrew Azores wrote:
>> Hi,
>>
>> This patch adds new menu items to the new popup menu where 
>> PolicyEditor can be launched. These new
>> items make it possible to run the current applet sandboxed, but with 
>> some additional permissions
>> added, without having to actually launch PolicyEditor and configure 
>> the permissions. These
>> permissions are also temporary, as opposed to making a custom policy, 
>> which persists until you
>> remove the policy.
>>
>> Right now the permission set defined is just the sum of the 
>> permissions PolicyEditor can grant via
>> its checkboxes, and the two options added are No File Access and No 
>> Network Access, which are just
>> that full set minus a few. I'd appreciate input on what other 
>> temporary permission options could be
>> made available.
>
> Only Sound
> Only clipboard
>
>  ? .. jsut ideas :)
>
> Generally I would like to have combinations, which allows to me most 
> of freedom, but protectme aginst gratest evils
>  - fiel accees
>  - network
>  - system.exec and simialr calls (yaaaaaaah!!)
>
> and ege sets of above
>  - no fiel accees nor networl
>  - network nor system exec
>  - system.exec nor fileacces
>  - non of those three
>
> ....
> agian - jsut ideas....

Okay, added a bunch like this, including Reflection as we discussed on 
IRC, and Runtime.exec which is actually FilePermission with execute 
action apparently (makes sense).

>
>>
>> Anyone have ideas on making the popup menu disappear nicely, rather 
>> than adding a setVisible call on
>> it to every action listener we have? And I suppose it should also be 
>> forced to disappear when the
>> dialog is disposed as well. What's the best practice for that?
>
> You can try lostfocus (it is actually window inside) or on 
> MouseExited). Each have its pross and cons...
>

Didn't end up using either, but problem is solved anyway using the 
show() method rather than setVisible(), I think.

>
>
>>
>> Thanks,
>>
>> -- 
>> Andrew A
>>
>
> This is extra cool :)
>>
>> temporary-permissions.patch
>>
>>
>> diff --git a/netx/net/sourceforge/jnlp/resources/Messages.properties 
>> b/netx/net/sourceforge/jnlp/resources/Messages.properties
>> --- a/netx/net/sourceforge/jnlp/resources/Messages.properties
>> +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties
>> @@ -302,6 +302,8 @@ SAuthenticationPrompt=The {0} server at
>>   SJNLPFileIsNotSigned=This application contains a digital signature 
>> in which the launching JNLP file is not signed.
>>   SAppletTitle=Applet title: {0}
>>   STrustedOnlyAttributeFailure=This application specifies 
>> Trusted-only as True in its Manifest. {0} and requests permission 
>> level: {1}. This is not allowed.
>> +STempPermNoFile=No file access
>> +STempPermNoNetwork=No network access
>>
>>   # Security - used for the More Information dialog
>>   SBadKeyUsage=Resources contain entries whose signer certificate's 
>> KeyUsage extension doesn't allow code signing.
>> diff --git a/netx/net/sourceforge/jnlp/security/Permissions.java 
>> b/netx/net/sourceforge/jnlp/security/Permissions.java
>> new file mode 100644
>> --- /dev/null
>> +++ b/netx/net/sourceforge/jnlp/security/Permissions.java
>> @@ -0,0 +1,24 @@
>> +package net.sourceforge.jnlp.security;
>> +
>> +import java.awt.AWTPermission;
>> +import java.io.FilePermission;
>> +import java.net.SocketPermission;
>> +import java.security.Permission;
>> +import java.util.PropertyPermission;
>> +
>> +import javax.sound.sampled.AudioPermission;
>> +
>> +public class Permissions {
>> +
>> +    public static final Permission READ_LOCAL_FILES = new 
>> FilePermission("${user.home}${/}*", "read");
>> +    public static final Permission WRITE_LOCAL_FILES = new 
>> FilePermission("${user.home}${/}*", "write");
>> +    public static final Permission READ_TMP_FILES = new 
>> FilePermission("${java.io.tmpdir}${/}*", "read");
>> +    public static final Permission WRITE_TMP_FILES = new 
>> FilePermission("${java.io.tmpdir}${/}*", "write");
>> +    public static final Permission READ_PROPERTIES = new 
>> PropertyPermission("*", "read");
>> +    public static final Permission WRITE_PROPERTIES = new 
>> PropertyPermission("*", "write");
>> +    public static final Permission NETWORK_ACCESS = new 
>> SocketPermission("*", "listen,connect,accept,resolve");
>> +    public static final Permission CLIPBOARD_ACCESS = new 
>> AWTPermission("accessClipboard");
>> +    public static final Permission PRINT_DOCUMENTS = new 
>> RuntimePermission("queuePrintJob");
>> +    public static final Permission PLAY_AUDIO = new 
>> AudioPermission("play");
>
> Arent those already deffineded? I think I saw them.. or something 
> really simialr. Cant it be reused?

You're probably thinking of PolicyEditorPermissions. They aren't 
actually the Permission objects to be granted, they're just models that 
in the end contain a few Strings, which are used for (de)serializing. I 
don't know of a simple prebuilt way to go from these models/string 
representations to the actual Permission objects. It could be reused by 
giving it a Permission field, and then adding a switch statement to 
check the PermissionType and set the field based on this, but that's a 
bit ugly. Up to you if this would be preferable.

>> +
>> +}
>> diff --git a/netx/net/sourceforge/jnlp/security/SecurityDialog.java 
>> b/netx/net/sourceforge/jnlp/security/SecurityDialog.java
>> --- a/netx/net/sourceforge/jnlp/security/SecurityDialog.java
>
>
> snip
>> +
>> +        final JMenuItem noFileAccess = new 
>> JMenuItem(R("STempPermNoFile"));
>> +        noFileAccess.addActionListener(new 
>> TemporaryPermissionsListener(
>> +                Permissions.NETWORK_ACCESS, 
>> Permissions.READ_PROPERTIES, Permissions.WRITE_PROPERTIES,
>> +                Permissions.CLIPBOARD_ACCESS, 
>> Permissions.PLAY_AUDIO, Permissions.PRINT_DOCUMENTS));
>> +        policyMenu.add(noFileAccess);
>> +
>> +        final JMenuItem noNetworkAccess = new 
>> JMenuItem(R("STempPermNoNetwork"));
>> +        noNetworkAccess.addActionListener(new 
>> TemporaryPermissionsListener(
>> +                Permissions.READ_LOCAL_FILES, 
>> Permissions.WRITE_LOCAL_FILES,
>> +                Permissions.READ_TMP_FILES, 
>> Permissions.WRITE_TMP_FILES,
>> +                Permissions.READ_PROPERTIES, 
>> Permissions.WRITE_PROPERTIES,
>> +                Permissions.CLIPBOARD_ACCESS, 
>> Permissions.PLAY_AUDIO, Permissions.PRINT_DOCUMENTS));
>> +        policyMenu.add(noNetworkAccess);
>> +
>>           policyMenu.setSize(policyMenu.getMinimumSize());
>
>
> Cant this be a bit more beter? I do not isnists, but imho tehre should 
> be some Interface "privledge provider"
>  With (now) two  implementations - Offline, NoFileAcces ...

It's a nice idea, but it seems like a bit more abstraction than is 
really needed for this task, doesn't it? I guess it would at least 
reduce the line count in the two dialogs. I don't think it's really 
worthwhile though.

>
> What do you think? Maybe something like this would be doable also for 
> the policies as they flew into ITW, isnt there somthing like that?
>
>
> J.
>

Thanks,

-- 
Andrew A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: temporary-permissions.patch
Type: text/x-patch
Size: 25523 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140324/a0119557/temporary-permissions-0001.patch>