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

[Andrew Azores]

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

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.

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

>
>> 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.
>>
>
> Thanx for thoughts,
>  J.
>

Thanks,

-- 
Andrew A