qrexec: offer also "Always Allow" option

[marmarek]

Reported by joanna on 17 Jul 2011 20:56 UTC
When there is no policy covering the (srcvm, dstvm, protol) then the user is prompt to allow/disallow the qrexec rpc. The prompt dialog box should also offer "Always allow" option that would automatically add rule to /etc/qubes_rpc/policy to further always allow this very tuple.

Migrated-From: https://wiki.qubes-os.org/ticket/278

[marmarek]

Comment by rafal on 19 Jul 2011 09:04 UTC
Please clarify and choose your medicine :)

When there is no policy covering the (srcvm, dstvm, protol) then the user is prompt to allow/disallow
the qrexec rpc.
Do you mean the case when there is NO policy file for a given action, and user gets "Please add a line in the form xxx to /etc/qubes_rpc/policy/actionname" ?

If the policy file exists, and there is no match in the rules, the action request is silently denied (just log to qrexec.X.log). There is no such case in the default policy files btw.

Perhaps you mean the case when the policy file specifies "ask" as the action (e.g. the default treatment of FileCopy requests) ?

The prompt dialog box should also offer "Always allow" option that would automatically add rule to
/etc/qubes_rpc/policy to further always allow this very tuple.
The problem is, the "zenity" tool does not offer ability to flexibly add options to dialog boxes. The closest I could find is

zenity  --list  --checklist  --column ignore --column ignore FALSE "Remember the action"  --hide-header --text "Do you allow X to do stuff?" --title "Confirmation request"

but:

1. the "OK" button does not have focus; user has to navigate to it, which is inconvenient (yes, it is much faster to clap Enter, than to pinpoint the button with mouse)
2. If you check "remember" box, and press Cancel, there is no information in the zenity status or output that the box was checked. In fact, there should be a separate button named "No" besides "Cancel" - but there is no way to add it.

Following each "ask" dialog with another separate one that says "remember the action you have just chosen?" is an option, but an annoying one IMHO.

[marmarek]

Comment by rafal on 19 Jul 2011 09:04 UTC
Please clarify and choose your medicine :)

When there is no policy covering the (srcvm, dstvm, protol) then the user is prompt to allow/disallow
the qrexec rpc.
Do you mean the case when there is NO policy file for a given action, and user gets "Please add a line in the form xxx to /etc/qubes_rpc/policy/actionname" ?

If the policy file exists, and there is no match in the rules, the action request is silently denied (just log to qrexec.X.log). There is no such case in the default policy files btw.

Perhaps you mean the case when the policy file specifies "ask" as the action (e.g. the default treatment of FileCopy requests) ?

The prompt dialog box should also offer "Always allow" option that would automatically add rule to
/etc/qubes_rpc/policy to further always allow this very tuple.
The problem is, the "zenity" tool does not offer ability to flexibly add options to dialog boxes. The closest I could find is

zenity  --list  --checklist  --column ignore --column ignore FALSE "Remember the action"  --hide-header --text "Do you allow X to do stuff?" --title "Confirmation request"

but:

1. the "OK" button does not have focus; user has to navigate to it, which is inconvenient (yes, it is much faster to clap Enter, than to pinpoint the button with mouse)
2. If you check "remember" box, and press Cancel, there is no information in the zenity status or output that the box was checked. In fact, there should be a separate button named "No" besides "Cancel" - but there is no way to add it.

Following each "ask" dialog with another separate one that says "remember the action you have just chosen?" is an option, but an annoying one IMHO.

[marmarek]

Comment by joanna on 20 Jul 2011 20:06 UTC

1. There should always be a policy file for any registered service, right? So if there is none, then we silently discard.

2. If there is a policy file for the service, but no there is no rule, then we ask.

3. When the re is a rule and it says "ask", then we ask.

If it is impossible to create (in a simple way) a dialog box with 3 buttons (Allow, Always Allow, Deny), then we should perhaps defer this task to Beta 3 and then create a sort python code for displaying this prompt window. Other alternatives suggested above are not really user-friendly (and the one with checklist is just ugly :P)

[marmarek]

Comment by joanna on 20 Jul 2011 20:06 UTC

1. There should always be a policy file for any registered service, right? So if there is none, then we silently discard.

2. If there is a policy file for the service, but no there is no rule, then we ask.

3. When the re is a rule and it says "ask", then we ask.

If it is impossible to create (in a simple way) a dialog box with 3 buttons (Allow, Always Allow, Deny), then we should perhaps defer this task to Beta 3 and then create a sort python code for displaying this prompt window. Other alternatives suggested above are not really user-friendly (and the one with checklist is just ugly :P)

[marmarek]

Comment by rafal on 21 Jul 2011 07:18 UTC

1. There should always be a policy file for any registered service, right? So if there is none, then we > silently discard.
   This makes sense - however, as we discussed, it results in the necessity to ship two rpms for each rpc service - one for appvm (with code) and one for dom0 (with policy file). Change this way ?

2. If there is a policy file for the service, but no there is no rule, then we ask.
   This is not good - we would have to also ask for additional parameters, like "run as root or user ?" "redirect to other vm"? And it should not be needed at all - there should always be "anyvm" line in the sane config for allowed combinations.

If it is impossible to create (in a simple way) a dialog box with 3 buttons (Allow, Always Allow,
Deny),
Not with zenity. There are other gui dialog creation tools, like gtkdialog; but if we decide to use one of them, then for consistency we would have to change all "zenity" occurrences in the code...

[marmarek]

Comment by rafal on 21 Jul 2011 07:18 UTC

1. There should always be a policy file for any registered service, right? So if there is none, then we > silently discard.
   This makes sense - however, as we discussed, it results in the necessity to ship two rpms for each rpc service - one for appvm (with code) and one for dom0 (with policy file). Change this way ?

2. If there is a policy file for the service, but no there is no rule, then we ask.
   This is not good - we would have to also ask for additional parameters, like "run as root or user ?" "redirect to other vm"? And it should not be needed at all - there should always be "anyvm" line in the sane config for allowed combinations.

If it is impossible to create (in a simple way) a dialog box with 3 buttons (Allow, Always Allow,
Deny),
Not with zenity. There are other gui dialog creation tools, like gtkdialog; but if we decide to use one of them, then for consistency we would have to change all "zenity" occurrences in the code...

[marmarek]

Modified by rafal on 25 Jul 2011 07:44 UTC

[marmarek]

Modified by rafal on 25 Jul 2011 07:44 UTC

[marmarek]

Modified by marmarek on 11 Oct 2011 09:47 UTC

[marmarek]

Modified by marmarek on 11 Oct 2011 09:47 UTC

[marmarek]

Comment by marmarek on 11 Oct 2011 22:14 UTC
http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=ede96353afed029b537e66a6232d74f7d9cafcdb

[marmarek]

Comment by marmarek on 11 Oct 2011 22:14 UTC
http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=ede96353afed029b537e66a6232d74f7d9cafcdb