provide an easy command line tool for copying between vm and dom0

[adrelanos]

(At the Tor summer dev meeting,) @bnvk, @mfc and I agreed that the instructions from https://www.qubes-os.org/en/doc/copy-to-dom0/, i.e. the command qvm-run --pass-io <src_domain> 'cat /path/to/file_in_src_domain' > /path/to/file_name_in_dom0 and philosophy we intentionally do not provide a convenient tool for copying files between VMs and Dom0 should be replaced with something more usable.

In my opinion, making even the command line difficult to use (even advanced users have to look up that syntax), adds extra difficulty to debugging issues (where dom0 logs need to be shared).

[marmarek]

On Sun, Oct 11, 2015 at 01:49:22PM -0700, Patrick Schleizer wrote:

(At the Tor summer dev meeting,) @bnvk, @mfc and I agreed that the instructions from https://www.qubes-os.org/en/doc/copy-to-dom0/, i.e. the command qvm-run --pass-io <src_domain> 'cat /path/to/file_in_src_domain' > /path/to/file_name_in_dom0 and philosophy we intentionally do not provide a convenient tool for copying files between VMs and Dom0 should be replaced with something more usable.

In my opinion, making even the command line difficult to use (even advanced users have to look up that syntax), adds extra difficulty to debugging issues (where dom0 logs need to be shared).

I think we should make a distinction here on the copy direction.

• dom0 -> VM (logs etc) - ok (related #953)
• VM -> dom0 - not so sure. This could easily lead to dom0 compromise for example when we talk about some shell script

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Sun, Oct 11, 2015 at 01:49:22PM -0700, Patrick Schleizer wrote:

(At the Tor summer dev meeting,) @bnvk, @mfc and I agreed that the instructions from https://www.qubes-os.org/en/doc/copy-to-dom0/, i.e. the command qvm-run --pass-io <src_domain> 'cat /path/to/file_in_src_domain' > /path/to/file_name_in_dom0 and philosophy we intentionally do not provide a convenient tool for copying files between VMs and Dom0 should be replaced with something more usable.

In my opinion, making even the command line difficult to use (even advanced users have to look up that syntax), adds extra difficulty to debugging issues (where dom0 logs need to be shared).

I think we should make a distinction here on the copy direction.

• dom0 -> VM (logs etc) - ok (related #953)
• VM -> dom0 - not so sure. This could easily lead to dom0 compromise for example when we talk about some shell script

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[bnvk]

• dom0 -> VM (logs etc) - ok (related #953)

Yah, that would be a HUGE usability improvement, simply for taking screenshots. I rarely move things from VM -> dom0 but find myself constantly hindered by the other route!

[bnvk]

• dom0 -> VM (logs etc) - ok (related #953)

Yah, that would be a HUGE usability improvement, simply for taking screenshots. I rarely move things from VM -> dom0 but find myself constantly hindered by the other route!

[adrelanos]

• VM -> dom0 - not so sure. This could easily lead to dom0 compromise for example when we talk about some shell script

What about requiring some extra option like --insecure or something?

[adrelanos]

• VM -> dom0 - not so sure. This could easily lead to dom0 compromise for example when we talk about some shell script

What about requiring some extra option like --insecure or something?

[mfc]

what is the usecase for VM -> dom0? I don't know if that is necessary, and I agree it is a vector for compromise.

For dom0 -> VM the usecases are:

• screenshots
• logs

[mfc]

what is the usecase for VM -> dom0? I don't know if that is necessary, and I agree it is a vector for compromise.

For dom0 -> VM the usecases are:

• screenshots
• logs

[marmarek]

For dom0->VM IMHO the best option would be to just have qvm-copy-to-vm
tool, with the same syntax as VM counterpart.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

For dom0->VM IMHO the best option would be to just have qvm-copy-to-vm
tool, with the same syntax as VM counterpart.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[bnvk]

I agree with @marmarek idea of having the same qvm-copy-to-vm
and qvm-move-to-vm would be the best base scenario for dom0 ->
VM

[bnvk]

I agree with @marmarek idea of having the same qvm-copy-to-vm
and qvm-move-to-vm would be the best base scenario for dom0 ->
VM

[rustybird]

@mfc:

what is the usecase for VM -> dom0?

Copying an SINIT blob to /boot for AEM would be one.

What do you think about this script: qvm-copy-from-vm [updated 2015-11-02 with --user=root instead of sudo, and --auto]

• It's short and simple, only supports file arguments (no directories)
• Safer than ad hoc qvm-run commands (where if the user forgets to redirect stderr to /dev/null, malicious stuff can leak into the dom0 terminal) [not true, I see that qvm-run always filters stderr for escape sequences, even if stdout is not a tty]
• Supports arbitrary file names (no shell quoting issues)
• Familiar syntax and behavior (files are saved to $HOME/QubesIncoming/srcvm, will not overwrite existing files)

[rustybird]

@mfc:

what is the usecase for VM -> dom0?

Copying an SINIT blob to /boot for AEM would be one.

What do you think about this script: qvm-copy-from-vm [updated 2015-11-02 with --user=root instead of sudo, and --auto]

• It's short and simple, only supports file arguments (no directories)
• Safer than ad hoc qvm-run commands (where if the user forgets to redirect stderr to /dev/null, malicious stuff can leak into the dom0 terminal) [not true, I see that qvm-run always filters stderr for escape sequences, even if stdout is not a tty]
• Supports arbitrary file names (no shell quoting issues)
• Familiar syntax and behavior (files are saved to $HOME/QubesIncoming/srcvm, will not overwrite existing files)

[marmarek]

@rustybird qvm-copy-from-vm implementation looks good. Maybe it would be better to force some target directory, to not forget that some file came from a VM.
The question is whether we want to have such tool at all? @rootkovska @mfc

[marmarek]

@rustybird qvm-copy-from-vm implementation looks good. Maybe it would be better to force some target directory, to not forget that some file came from a VM.
The question is whether we want to have such tool at all? @rootkovska @mfc

[rustybird]

@marmarek:

Maybe it would be better to force some target directory, to not forget that some file came from a VM.

The files are already saved at ~/QubesIncoming/src_vmname:
https://gist.github.com/rustybird/625e018ed280c18b49f7#file-qvm-copy-from-vm-L11-L13

[rustybird]

@marmarek:

Maybe it would be better to force some target directory, to not forget that some file came from a VM.

The files are already saved at ~/QubesIncoming/src_vmname:
https://gist.github.com/rustybird/625e018ed280c18b49f7#file-qvm-copy-from-vm-L11-L13

[rootkovska]

1. I agree we might extend qvm-{copy,move}-to-vm tools to also support copying of files from Dom0 to AppVMs.
2. I'm not so convinced we should be supporting the other direction (VM -> Dom0). E.g. I don't think Dom0 should be used for preparing AEM sticks -- e.g. I use for that a one-time dedicated VM with USB controller assigned. Do we have other scenarios for legitimate VM -> Dom0 transfers?

[rootkovska]

1. I agree we might extend qvm-{copy,move}-to-vm tools to also support copying of files from Dom0 to AppVMs.
2. I'm not so convinced we should be supporting the other direction (VM -> Dom0). E.g. I don't think Dom0 should be used for preparing AEM sticks -- e.g. I use for that a one-time dedicated VM with USB controller assigned. Do we have other scenarios for legitimate VM -> Dom0 transfers?

[rustybird]

@rootkovska:

E.g. I don't think Dom0 should be used for preparing AEM sticks -- e.g. I use for that a one-time dedicated VM with USB controller assigned.

What about internal AEM devices (i.e. the system boot partition)? Especially now that AEM supports portable Qubes installations.

Do we have other scenarios for legitimate VM -> Dom0 transfers?

Occasionally, users are instructed to transfer a .rpm to dom0 and install it manually (after verification with rpm -K):

https://groups.google.com/forum/#!searchin/qubes-users/%22rpm$20k%22
https://groups.google.com/forum/#!searchin/qubes-devel/%22rpm$20k%22

[rustybird]

@rootkovska:

E.g. I don't think Dom0 should be used for preparing AEM sticks -- e.g. I use for that a one-time dedicated VM with USB controller assigned.

What about internal AEM devices (i.e. the system boot partition)? Especially now that AEM supports portable Qubes installations.

Do we have other scenarios for legitimate VM -> Dom0 transfers?

Occasionally, users are instructed to transfer a .rpm to dom0 and install it manually (after verification with rpm -K):

https://groups.google.com/forum/#!searchin/qubes-users/%22rpm$20k%22
https://groups.google.com/forum/#!searchin/qubes-devel/%22rpm$20k%22

[rootkovska]

If we concluded we absolutely needed a tool in Dom0 (for easier) transfer of files to Dom0, then I like the idea Patrick proposed with requiring an explicit --insecure switch (even if the tool was only for transferring files to Dom0 and had no other purpose).

[rootkovska]

If we concluded we absolutely needed a tool in Dom0 (for easier) transfer of files to Dom0, then I like the idea Patrick proposed with requiring an explicit --insecure switch (even if the tool was only for transferring files to Dom0 and had no other purpose).

[adrelanos]

Joanna Rutkowska:

If we concluded we absolutely needed a tool in Dom0 (for easier)
transfer of files to Dom0, then I like the idea Patrick proposed with
requiring an explicit --insecure switch (even if the tool was only
for transferring files to Dom0 and had no other purpose).

But now I am disagreeing with my earlier self. :)

Minor point... I was wondering how it would work out on a mailing
list... Users are told then to use the tool for copying between vm and
dom0 and adding the --insecure switch. Then we'd get follow up questions
and need to explain "oh, in this case, that's okay'. Not a huge issue,
also not great.

@bnvk any idea?

'--i-know' perhaps? :)

Anyhow. Let's not get lost in this. I'll go with whatever you judge best.

[adrelanos]

Joanna Rutkowska:

If we concluded we absolutely needed a tool in Dom0 (for easier)
transfer of files to Dom0, then I like the idea Patrick proposed with
requiring an explicit --insecure switch (even if the tool was only
for transferring files to Dom0 and had no other purpose).

But now I am disagreeing with my earlier self. :)

Minor point... I was wondering how it would work out on a mailing
list... Users are told then to use the tool for copying between vm and
dom0 and adding the --insecure switch. Then we'd get follow up questions
and need to explain "oh, in this case, that's okay'. Not a huge issue,
also not great.

@bnvk any idea?

'--i-know' perhaps? :)

Anyhow. Let's not get lost in this. I'll go with whatever you judge best.

[rootkovska]

But, AFAIU, all these cases when the user is asked to copy rpms to Dom0 are some special cases related to special testing/development only. I think it would be fine to require passing of --insecure then. But then again, I also think in such a case it should be just enough to expect the user to use qvm-run -p....

To summarize this threat: I think there is value in implementing a Dom0->VM tool (running in Dom0 and named like the AppVM tools, i.e. qvm-{copy,move}-to-vm, and placing the files into ~/QubesIncoming/dom0) for logs and screenshots mostly. I would not rush to implement any tool for the other direction at this point.

BTW, we should also make sure the user is not able to create a VM named "{D,d}om0" :)

[rootkovska]

But, AFAIU, all these cases when the user is asked to copy rpms to Dom0 are some special cases related to special testing/development only. I think it would be fine to require passing of --insecure then. But then again, I also think in such a case it should be just enough to expect the user to use qvm-run -p....

To summarize this threat: I think there is value in implementing a Dom0->VM tool (running in Dom0 and named like the AppVM tools, i.e. qvm-{copy,move}-to-vm, and placing the files into ~/QubesIncoming/dom0) for logs and screenshots mostly. I would not rush to implement any tool for the other direction at this point.

BTW, we should also make sure the user is not able to create a VM named "{D,d}om0" :)

[rustybird]

The latest gist revision has --insecure, FWIW

[rustybird]

The latest gist revision has --insecure, FWIW

[woju]

On Wed, Nov 04, 2015 at 03:26:00AM -0800, Rusty Bird wrote:

The latest gist revision has --insecure, FWIW

Another idea: for some operation (linking some basic tools to busybox
AFAIR) Gentoo required setting environmental variable
VERY_BRAVE_OR_VERY_STUPID=1

[woju]

On Wed, Nov 04, 2015 at 03:26:00AM -0800, Rusty Bird wrote:

The latest gist revision has --insecure, FWIW

Another idea: for some operation (linking some basic tools to busybox
AFAIR) Gentoo required setting environmental variable
VERY_BRAVE_OR_VERY_STUPID=1

[rustybird]

I don't have a strong opinion either way, but while we're collecting ideas:

• Maybe a flaw with these kind of switches is they make it seem like the command itself is insecure, as opposed to handling the file afterwards. So a user might improvise a worse method, e.g. attaching a USB drive to the source VM and then to dom0.
• They kind of imply that, in contrast, inter-VM copy is inherently secure. But of course handling the files in the destination VM afterwards brings the same danger, just in a more contained environment.

[rustybird]

I don't have a strong opinion either way, but while we're collecting ideas:

• Maybe a flaw with these kind of switches is they make it seem like the command itself is insecure, as opposed to handling the file afterwards. So a user might improvise a worse method, e.g. attaching a USB drive to the source VM and then to dom0.
• They kind of imply that, in contrast, inter-VM copy is inherently secure. But of course handling the files in the destination VM afterwards brings the same danger, just in a more contained environment.

[adrelanos]

Good points.

[adrelanos]

Good points.

[marmarek]

Command line tool for dom->VM is done.
It would be nice to have also GUI equivalent (which would prompt for target VM name). Then it would be trivial to plug it into screenshooting tools - appropriate .desktop file just needs to have MimeType=image/png;. It would look like:

[Desktop Entry]
Type=Application
Name=Save image to VM
Exec=qvm-move-to-vm-prompt %F
MimeType=image/png;
NoDisplay=true

I've tried to do some simple script for that, but failed on actual VM name prompt tool - kdialog --combobox should be enough, but it isn't available in Xfce install (and have a lot of KDE dependencies). zenity doesn't have such feature - only simple text entry

[marmarek]

Command line tool for dom->VM is done.
It would be nice to have also GUI equivalent (which would prompt for target VM name). Then it would be trivial to plug it into screenshooting tools - appropriate .desktop file just needs to have MimeType=image/png;. It would look like:

[Desktop Entry]
Type=Application
Name=Save image to VM
Exec=qvm-move-to-vm-prompt %F
MimeType=image/png;
NoDisplay=true

I've tried to do some simple script for that, but failed on actual VM name prompt tool - kdialog --combobox should be enough, but it isn't available in Xfce install (and have a lot of KDE dependencies). zenity doesn't have such feature - only simple text entry

[rootkovska]

BTW, I forgot about one important scenario about moving files from an AppVMqubes to dom0admin (admin what? admin qube?): namely setting up the wallpaper. Of course the proper way of doing that is to pipe this through our trusted image converter. I also remember we talked once about exposing a simple qrexec service (qubes.SetWallpaper) and a user-visible command in AppVMsqubes, e.g.:

qvm-set-system-wallpaper <filename>

Plus a trivial integration with Nautilus for the context menu.

[rootkovska]

BTW, I forgot about one important scenario about moving files from an AppVMqubes to dom0admin (admin what? admin qube?): namely setting up the wallpaper. Of course the proper way of doing that is to pipe this through our trusted image converter. I also remember we talked once about exposing a simple qrexec service (qubes.SetWallpaper) and a user-visible command in AppVMsqubes, e.g.:

qvm-set-system-wallpaper <filename>

Plus a trivial integration with Nautilus for the context menu.

[andrewdavidwong]

BTW, I forgot about one important scenario about moving files from an AppVMqubes to dom0admin (admin what? admin qube?): namely setting up the wallpaper. Of course the proper way of doing that is to pipe this through our trusted image converter.

Why not simply display the wallpaper in a fullscreen qube, then take a screenshot from dom0?

[andrewdavidwong]

BTW, I forgot about one important scenario about moving files from an AppVMqubes to dom0admin (admin what? admin qube?): namely setting up the wallpaper. Of course the proper way of doing that is to pipe this through our trusted image converter.

Why not simply display the wallpaper in a fullscreen qube, then take a screenshot from dom0?

[marmarek]

Because it's tricky to display an image in fullscreen, especially in case of multi-monitor setup. Also it will (depending on image) reduce its resolution, so will be useless after changing dom0 resolution.

[marmarek]

Because it's tricky to display an image in fullscreen, especially in case of multi-monitor setup. Also it will (depending on image) reduce its resolution, so will be useless after changing dom0 resolution.

[andrewdavidwong]

I have no problems displaying an image fullscreen on a single monitor, but yes, multiple monitors is tricky. (An easy solution to the resolution issue is simply to take the screenshot again at the new resolution.)

Edit: Actually, can't you use xrandr to temporarily artificially set the resolution of dom0 to be larger than your monitor's resolution, then take the screenshot at the full resolution of the source image?

[andrewdavidwong]

I have no problems displaying an image fullscreen on a single monitor, but yes, multiple monitors is tricky. (An easy solution to the resolution issue is simply to take the screenshot again at the new resolution.)

Edit: Actually, can't you use xrandr to temporarily artificially set the resolution of dom0 to be larger than your monitor's resolution, then take the screenshot at the full resolution of the source image?

[evadogstar]

https://github.com/evadogstar/qvm-wallpaper-tool/

Maybe to start with something. Current version:
This tool convert image (only jpg and png for security reasons) at AppVM where image is located. Then image downloaded to dom0
Then converted again at dom0

Now without GUI and does not know how to set wallpapers at xfce & kde. Tried some code, but it does not work

qvm-wallpaper-tool <AppVM> /path/to/jpg/at/appvm

#215 link

[evadogstar]

https://github.com/evadogstar/qvm-wallpaper-tool/

Maybe to start with something. Current version:
This tool convert image (only jpg and png for security reasons) at AppVM where image is located. Then image downloaded to dom0
Then converted again at dom0

Now without GUI and does not know how to set wallpapers at xfce & kde. Tried some code, but it does not work

qvm-wallpaper-tool <AppVM> /path/to/jpg/at/appvm

#215 link

[unman]

@andrewdavidwong I would suggest that this can be closed, since there seems little appetite for qube to dom0 copying, (with exception of wallpaper and there is separate ticket for that), and there is now dom0 to qube tool.

[unman]

@andrewdavidwong I would suggest that this can be closed, since there seems little appetite for qube to dom0 copying, (with exception of wallpaper and there is separate ticket for that), and there is now dom0 to qube tool.

[evadogstar]

qvm-get-image now do the job
and close linked ticket #215

[evadogstar]

qvm-get-image now do the job
and close linked ticket #215