Consider an option to ask for RPC target VM in dom0

[marmarek]

Reported by marmarek on 28 Oct 2014 13:49 UTC
This would allow for example copy some files out of VM, without telling the VM name of target VM.

In case of filecopy, it would not change user experience - user will still get a single prompt for VM name. In fact it will even simplify some things:

• can get rid of ugly VM name prompt on Windows
• can use the same script for nautilus and dolphin (no need to use zenity/kdialog to match the interface there)
• finally - can use the same prompt for VM name and service confirmation (when policy says "ask")

Technically, when source VM sends empty target VM field in service request, qrexec-policy would handle this case and show the prompt, instead of failing the request.

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

[marmarek]

Comment by marmarek on 28 Oct 2014 13:52 UTC
Additionally dom0 know full VM list, so it can be drop-down list, without a risk of information leak.

Discussion:
https://groups.google.com/d/msg/qubes-users/0lIEQ01gtDA/ajxcuT_GqmsJ

[marmarek]

Comment by joanna on 31 Oct 2014 12:07 UTC
Yes. But I think in R3.

[rootkovska]

See: https://groups.google.com/forum/#!msg/qubes-devel/xLZU0R5ijCg/_Lk1tXp9BwAJ

[marmarek]

Moving discussion from #2436:

I think the target VM argument should be preserved. There are multiple cases when you want to simply allow action for specific target VM without bothering user with confirmation. For example in 'devel' VM you may want to copy the outcome to some 'testing' VM where you run various tests. You don't want to select 'testing' VM hundreds times a day (you have a script to call qvm-copy-to-vm, or simply call it from shell history), but on the other hand you still may want to occasionally copy some files to a different VM.

This means I wouldn't touch the cases when policy explicitly says 'allow'. If you have policy some-vm $anyvm allow, it means that 'some-vm' VM will be able to learn list of VMs. If you don't want that, do not add such line to the policy.

The case of 'deny' action for existing vs non-existing target VM is easy - error message (if any) should not be blocking.

I should note that policy right now allow also to override target VM choice. You may specify something like:

some-vm $anyvm allow,target=another-vm

Currently it means "whatever existing target VM name (if any) was provided, redirect service to another-vm". Should be: "whaveter target VM name is, redirect service to another-vm". Of course unless earlier rule says otherwise.

The thing to reconsider is what about 'ask' action. There are few cases:

• calling VM provided target VM and it exists (and policy says 'ask')
• calling VM provided target VM and it does not exist (but default action says 'ask')
• calling VM did not provided target VM at all (and default action says 'ask')

Currently each of those cases are handled differently:

• if target VM is provided and it exists you get the confirmation prompt, if it does not exists, you get (blocking) error message
• if target VM is not provided, it is this ticket - user should be prompted to select one

I think non-existing target VM should be treated as no target VM provided at all (still - if the default action is 'ask').

So, we have two things to design:

• what VMs should be listed in the prompt - initial idea was: all whose policy action would be "allow" or "ask".
• (related to above) how to differentiate - if desired at all - between target VM selected in service call and target VM selected by the user in policy prompt - this IMO applies only to 'ask' action - should the policy prompt for specific target differ from prompt without target VM specified? Or maybe both should allow to select target VM, even if caller provided one?

And some UX issue: what should be the default target in that dialog (if any). If called provided one - I think it should be used), but otherwise - anything at all?
/cc @jpouellet

[jpouellet]

A first thought is to have the list of VMs always displayed, and the source-specified intended-target be the initial selection of that dropdown (or in case of text box: have it pre-populated with name of intended target). I don't know how I feel about that though, since I feel like it leads to building a user habit of simply pressing enter whenever source-suggested target exists, and what happens when one day the source is malicious and suggests a different target? User habit is still to press enter! Would they even notice the difference? Likely not...

Therefore, I think handling both "ask" cases (with and without suggested target) as if there were never a suggested target would be a good thing.

Another case we need to consider is an ... ... ask,target=foo rule. Is this even meaningful anymore? If so, which target should win (user specified vs. target=)?

[marmarek]

and what happens when one day the source is malicious and suggests a different target? User habit is still to press enter! Would they even notice the difference? Likely not...

The point is to have only subset of VMs there - so it should be impossible to execute "dangerous" operation. Of course for that, someone would need to select which VMs should be there (set policy to 'deny' for others - or even 'deny' by default and 'ask' for a few). And the case you've described is exactly what we currently have - only a confirmation of what calling VM requested. I'm not saying it's the best possible, but not bad either. I think much bigger problem with it is focus stealing (#1166) - it's simple enough to guess when user will press enter and execute some qrexec operation just before...

Another case we need to consider is an ... ... ask,target=foo rule. Is this even meaningful anymore? If so, which target should win (user specified vs. target=)?

That's a good question. I'd say in that case, target= means what should be suggested, but the final decision is up to the user. Maybe this is the way to go: have target VM prefilled only when defined as such in policy, otherwise empty by default (even when specified by source VM)?

[jpouellet]

I think much bigger problem with it is focus stealing

I agree, but my point was that even with perfect focus stealing prevention, pre-populating target in UI according to suggestion from (un-trusted!) rpc source seems to me a bad idea. It conditions users to accept the default, where the default is attacker-controlled.

That's a good question. I'd say in that case, target= means what should be suggested, but the final decision is up to the user.

Sounds reasonable to me.

Maybe this is the way to go: have target VM prefilled only when defined as such [target=] in policy, otherwise empty by default (even when specified by source VM)?

Yes. This sounds to me like the best option.

[boring-stuff]

Hi, I'd like to start on this.
Should I begin with implementing the Qt dialog first, the best place for this looks like guihelpers.py? I'd then integrate it in qrexec-policy and allow an empty target.

Also, should I follow any particular Qt guidelines at all?

[marmarek]

Actually, GTK would be better, as new Qubes Manager would be in GTK, and also it will be more consistent with now default Xfce environment. I think it's better to create separate python file this GUI dialog.
Anyway the overall plan looks ok :)

[boring-stuff]

Noted.
I've prototyped the window in glade and am hooking onto the elements via IDs, so that designers can later on change the .glade file without touching the code.
I'd also shoot for a re-usable python class that leverages a gtk combobox listing a subset of the domains, including colored icons.

Question: how's the test strategy here? Are they all integration tests, or are there unit tests as well? How can I add testcases, and run them in a local environment? Are they all in tests, or somewhere else?

[andrewdavidwong]

Thanks for taking this on, @boring-stuff! I've added this to the community-developed feature tracker.

[marmarek]

later: launch GUI part as separate process, inside user session (through d-bus?) - this will be required for GUI domain, where mere setting DISPLAY is not enough

Chosen this option right now - it was just few lines of code.

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.0-1.fc24 has been pushed to the r4.0 testing repository for the Fedora fc24 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.0-1.fc25 has been pushed to the r4.0 testing repository for the Fedora fc25 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.0-1+deb8u1 has been pushed to the r4.0 testing repository for the Debian jessie template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing jessie-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.0-1+deb9u1 has been pushed to the r4.0 testing repository for the Debian stretch template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update