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

[Jiri Vanek]

On 01/15/2014 11:34 PM, Andrew Azores wrote:
> 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

I do not like the idea of list :( (on the other side the advanced security list can be reused - but 
it will require "unsigned applet wants to run" dialogue shown after "run in sandbox button")

I can not imagine person, setting up policies, and not bale to set codebase... (eg my mom setting 
the policies :) )
Its admin's work.  So I would like (next to ~/.config/icedtea/security/java.policy) to see also 
global policy file instead.

> 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
We do not have yet;)

> 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.
Sounds reasonable.

>
> 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

Yes, I like that - "advance" which will lunch policytool as now, and "basic" which will invoke 
custom "mini tool". Please note, that they have to share the policy file.

> 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.
>

Thanx for thoughts,
  J.