[rfc][icedtea-web] policytool in itweb-settings

[Andrew Azores]

On 01/15/2014 04:08 PM, Deepak Bhole wrote:
> * Jiri Vanek <jvanek at redhat.com> [2014-01-15 09:26]:
>> On 01/14/2014 07:15 PM, Deepak Bhole wrote:
>>>
>>> Hi Jiri,
>>>
>>> How so? The editor we have in mind for ITW is to set policies for
>>> applets/JNLP apps. Why the need to have it accepted upstream (not that I
>>> am against it)?
>>>
>>> The editor will be geared toward setting policies for untrusted apps for
>>> the most part (e.g. checkboxes for "allow read/write to filesystem",
>>> "allow network connection" etc. and some additional customizations. In
>>> general it would be too restrictive for the kind of complex policies
>>> that administrators would want to set for complex Java applications.
>>>
>> Hi!
>>
>> Well the policy tool do exists, and can be reused.  There is no need to re-implement it.
>> If so, then in the most correct place of all - the jdk (where
>> current policy tool is). Then others (even itw) will gain benefits
>> from it.
>> We can add some simple editor for most common cases (as I understand
>> form your comment is what you wont). But not rewrite it on our own.
>>
>> Thanx for watch!
>>
> Perhaps it makes sense to first determine what we want and settle on
> that first (as rfc) then before we try to implement (either standalone
> or updating policytool).
>
> Andrew, did you have a specific design in mind? If so, can you provide
> quick mockups?
>
> Thanks,
> Deepak

I don't have any ideas as far as the visual design for the editor, no. 
But I do have some ideas about the general interface it should expose to 
users.

I was thinking that we might have some kind of way for the editor to 
show a list of recently run applets and let the user select from this 
list, in order to build a policy entry applicable to that applet (ie by 
using its codebase). There would also be a way for the user to manually 
specify the codebase in a text field or something. This sounds kind of 
bad, because it means users either have to be advanced enough to know 
how to specify the applet's codebase, or they need to run the applet 
first before being able to restrict its permissions, which kind of 
defeats the purpose. *However* - we have a "Run in Sandbox" button! So 
users who intend to create a custom policy for an applet can run it 
first, in Sandbox since they don't fully trust it, and then edit a 
custom policy for it and add the minimal permissions required to get it 
to run. The only thing that will be confusing here and require some kind 
of explanation is that for the restricted permissions policy to take 
effect, the user needs to continue choosing Sandbox - even with the 
custom policy in place, if the user chooses to run the applet with the 
standard Ok/Proceed button, then the custom policy won't apply. Well, it 
will, but AllPermission will be granted on top, rendering it effectively 
useless. Maybe "Sandbox" should be relabelled as "Restricted Run" or 
similar then, since it won't really be Sandbox anymore once custom 
policies are in place.

For actually specifying permissions, there could be an "Advanced" button 
to show a full listing of options, much like the existing policytool, 
but the standard interface would just have checkboxes for "Allow network 
connections", "Allow local filesystem access", "Allow printing", "Allow 
reading user details", "Allow all actions", etc. Each of these would add 
or remove a small set of permissions to the policy, eg "Allow reading 
user details" would entail granting read permission on the user.name and 
probably user.home together. Or really, I imagine a user that is both 
advanced enough to care about making a custom policy AND needs more 
control than the coarse-grained checkboxes is probably advanced enough 
to deal with the existing policytool. So we can just leave out the 
Advanced-type settings from the new editor and let those users deal with 
using the existing policytool if they need it. Maybe PolicyPanel could 
be modified further to allow users to choose which editor to launch with 
an "advanced" checkbox or similar.

Thanks,

-- 
Andrew A