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

[Andrew Azores]

On 01/16/2014 05:44 PM, Jacob Wisor wrote:
> 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. ;-)
>

We're giving the user two levels - full and restricted. By default, 
restricted is fully sandboxed permissions. You can add permissions to 
this level  on a per-applet basis, but if you do this, then the only way 
to return to fully sandboxed permissions for this applet is to simply 
remove the extras you've granted. There are no "three or four security 
levels". Conceptually, it is a map from apps to sets of permissions, and 
the value assigned to each new key is either "fully sandboxed" or "all 
permissions", depending on applet signing (and the "Run in Sandbox" 
button being discussed in another thread as well as mentioned at the 
bottom of this mail). This patch allows you to add permissions into 
these sets. If you are a user like this who doesn't care about the 
security implications of granting AllPermission and simply want to get 
the job done, then you just never play with custom policies and the "Run 
in Sandbox" button, and continue running will full permissions as you 
have all along.

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

I don't see how this means we shouldn't give the ability. Yes, it would 
certainly be more useful if there was an established negotiation 
protocol, but I still think offering power users the choice to do this 
is better than not offering it and forcing them to grant AllPermission 
to any app that asks for it, if they want to run the app at all. Without 
the app developers explicitly telling you what permissions you need then 
it certainly will be a tedious trial and error process, but the 
important thing is that we make it possible. Would it be preferable if 
we had a better security model to build off of? Certainly. But let's try 
to do what we can with the existing security model before going and 
trying to redesign the language.

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

Yes, the security dialog prompts do exactly this - more along the lines 
of UAC than sudo/polkit visually (since there is no password prompt 
involved). You can run the applet and trust it this time only, or you 
can run the applet and trust it permanently, or you can simply not run 
the applet. If you choose to run the app at all, it is already granted 
AllPermission, so I don't see what the issue is here in regards to the 
patch at hand. The concept of adding a choice here to run the applet 
this time only in a sandboxed environment is currently being discussed 
in another thread on this mailing list. That patch adds a button to the 
prompt that appears before running a signed app which allows the user to 
choose to run the app with sandbox permissions rather than granting it 
all permissions. With a properly constructed custom policy in place 
however, "sandbox" becomes "restricted" as I outlined earlier - it is a 
safe sandbox, *plus* a set of user-defined additional permissions. This 
is exactly why I want to have both of these patches go in together - on 
their own, each is not of very much use. Together, they are quite powerful.

Thanks,

-- 
Andrew A