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

[Jacob Wisor]

On 01/16/2014 04:13 PM, Andrew Azores wrote:
> On 01/16/2014 10:03 AM, Jiri Vanek wrote:
>> On 01/16/2014 03:58 PM, Andrew Azores wrote:
>>>>> 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?!?!?
>>
>
> Woah, what? This is not what I meant at all :) The dialogs shown at applet run
> time will just have "Ok/Proceed", "Sandbox" (or "Restricted" or whatever), and
> "Cancel". Sandbox/Restricted will run the applet with reduced permissions,
> meaning the Sandbox permission set, union the permission set defined in the user
> policy file (as well as system policy file). The Advanced button was just going
> to be either in itweb-settings control panel or in the "mini editor" itself and
> provide a way to either simply show more policy options or to launch JDK
> policytool, to give power users more control over the policy they are editing. I
> definitely am not planning to have two different types of Sandbox button.
>
> It is an interesting idea though to have the dialog present a button for policy
> editing. This would make it very easy for users to find the correct codebase for
> an applet, since we could fill it in for them already. I'm not sure if adding
> yet another button would be very good visually though - it might be too much
> going on on one dialog and become confusing. Or, rather than adding a way to
> launch the policy editor here during run time (which sounds a little unsafe to
> me), we could simply add a button to the dialog somewhere to copy the applet
> codebase to the clipboard. Then the user can cancel or sandbox, then later open
> the editor and paste the codebase? Hmm.

After reading all of that discussion, I am beginning to believe that everything 
comes down again to that major usability design flaw of J2SE permissions framework.
Providing the user with an option of three or four security levels or 
containment boxes (or sandboxs - whatever you call it) to achieve more security 
and safety for the broadest user base is probably a futile attempt. Most users, 
and especially those least technically versed will simply click or choose what 
makes an application work for them, regardless of the security risks involved. 
Simply because they are not interested in security or sandbox concepts. They are 
interested in completing their task with the help of an application at hand: And 
heck, if it means that the easiest way to get that damn thing of computer 
running for me is to give the app AllPermissions, before my boss comes in on me 
and asks me to stop playing with the buttons and to get back doing my job, then 
that's exactly what I am going to do. ;-)

The reason why Android's security model works for the broadest user audience 
/relatively/ well, is because it is actually on developers of every single 
application to request permissions or access to specific resources before run 
time. J2SE imposes no such requirement on developers, nor does it specify a 
protocol on *how* users or admins should negotiate, grant, and deny permissions 
for a specific application. And, this is exactly what J2SE's security model is 
lacking: A permissions *negotiation* protocol. So, even if a user, a power user, 
or an admin is confronted with or offered a more or less detailed permission 
settings dialog, he/she still does not know what a safe setting (policy) for 
that particular application looks like. Unless of course, the user is provided 
with an exact documentation of that particular application's security sensitive 
operations and thus required permissions to operate properly. And, as we all 
know this is most often not the case. :-/

So, I would like to ask you, Andrew and Jiri especially, to think again about 
what you are actually trying to achieve with this. Well, for me it is a design 
flaw of J2SE so that there is a better place to address this than the 
IcedTea-Web Settings panel. Or perhaps I should rather say that this matter has 
to be addressed on a much deeper level than an applet launcher UI.
This being said, have you thought of perhaps implementing a Windows UAC or 
sudo/polkit like approach? Asking the user for a one time permission only (with 
an option to store this permission with the current parameter set) when it is 
actually required at run time may solve the problem (without having to fix 
J2SE's security model). I am well aware that this isn't the best way to 
implement a user friendly security model but firstly, you do not have the risk 
of users abundantly granting AllPermissions just because its easier and 
secondly, you have a complete sandbox by default (no permissions at all). What 
do you think?

Jacob