[rfc][icedtea-web] policytool in itweb-settings
aazores at redhat.com
Thu Jan 16 06:58:50 PST 2014
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.
>>>> 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?
>> 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
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
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
>> 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,
More information about the distro-pkg-dev