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

[Jiri Vanek]

On 01/16/2014 03:58 PM, Andrew Azores wrote:
> On 01/16/2014 09:39 AM, Jiri Vanek wrote:
>> 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.
>
> Well, admins can continue using policytool if they need to. IMO the point of making a more user
> accessible editor tool like this, combined with the Sandbox (or whatever) button, is so that the

Fair enough.

> advanced-but-not-admin level users can have some control over the individual applets they may be
> running on their system. We don't *have* to have a list of recently run applets for them to choose
> from, but I think there should be maybe some easier way available than specifying the codebase
> manually. Otherwise, it will only be power users and admins ever using this tool, but it would be
> better if more users than that were able to take some control over the permissions granted to
> applets they run.
>
> Anyway - the "unsigned applet wants to run" dialog is currently being updated to also have a Run in
> Sandbox button. When that's done then the extended security panel in itweb-settings will be able to
> list applets that were run in sandbox, just like how it lists yes/always/no/never runs currently.
> Once both of these parent patches go in, then I'll work on that more and try to get it ready for
> review.  Right now I'm having some difficulties with the fact that it's apparently required to be
> called after classloader initialization completes. But that's a discussion for a different thread.

/Me wondering a bit, but waits for patch
>
> What do you mean about the global policy file? That one is already implemented in our policy
> handling just like the user-level policy, so if we want to make use of that then all we need to do
> is provide a way to edit it. I'm not sure if the path to it is already available in the
> DeploymentConfiguration but if it is then this is pretty trivial to add in, and is still easy if not.

Sounds reasonable to try.
>
>>
>>> 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;)
>
> Not yet, but we are going to, aren't we? If not then the custom policies implementation will need
> some significant changes in order to make any sense :)

Sure.

>
>>
>>> 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.
>
> Yes, of course they'd be editing the same 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.
>>>
>>
This remianed me:

You are planing to have "run in 'advacned' sandbox" button next to run i sandbox, which will allow 
to set permissions before (and for) actual run (with possibility of save eg?) Or did I just imagined 
it from nothing?!?!?


J.