-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Dec 21, 2016 at 05:35:37PM +0000, john.david.r.smith wrote:
> what do you think about adding such a `qvm-inter-vm-copy`-command to dom0?
> (the functionality (intervm copy) should mostly already be there).
> 
> Or is there some other/better way?

Few ideas:
1. Implement poor man qvm-inter-vm-copy like this:

    qvm-run -p source-vm 'tar c source-file-dir' | qvm-run -p dest-vm
'tar x -C dest-dir'

Better use qfile format instead of tar, to have something even simpler,
but currently qfile-unpacker (equivalent for 'tar x') have hardcoded
QubesIncoming path. In this case it isn't that important because the
transfer is unidirectional, from more trusted to less trusted (at least
I assume that configvm in your case is indeed more trusted, right?).

2. Implement simple service for target VM to ask for specific file/dir from
config VM. This needs to be done carefully, to really allow only
selected file/dir, not anything else. Qrexec service argument could be
used for this. So target VM could download the file
for itself (this can be called from salt, rc.local or anywhere else).

Proof of concept:

configvm:/usr/local/etc/qubes-rpc/local.GetFileDir (executable):

    #!/bin/sh

    set -e

    # allow access only to files/directories in ConfigData directory
    cd /home/user/ConfigData

    # use tar to handle directories too; $1 is service argument (see
    # below); qrexec policy already sanitized '/' and other dangerous
    # characters in policy argument, by replacing them with '_'
    tar c $1

dom0:/etc/qubes-rpc/policy/local.GetFileDir+somefilename:

    # allow transfer of /home/user/ConfigData/somefilename to
    # dest-vm
    dest-vm configvm allow
    
    # deny transfer somefilename anywhere else (can be omitted, as
    # default action is deny)
    $anyvm $anyvm deny

dom0:/etc/qubes-rpc/policy/local.GetFileDir:

    # deny any call without argument, or with argument not explicitly
    # allowed/denied above; without this file, you'd get rather annoying
    # prompt to create policy file (but the call would not be allowed
    # without your explicit consent)
    $anyvm $anyvm deny


dest-vm - retrieve file(s):

    # extract to the current directory
    qrexec-client-vm configvm local.GetFileDir+somefilename | tar x


You can also go with easier option - creating per-VM directory and
creating a service allowing the transfer of this directory only (instead
of selected one). Basically use $QREXEC_REMOTE_DOMAIN instead of $1 in
the first script. And drop argument (the thing after '+') from policy
and the qrexec-client-vm call.

More details here:
https://www.qubes-os.org/doc/qrexec3/

PS It is not widely known feature that VM's local service files can be
also in /usr/local/etc/qubes-rpc/, not only in /etc/qubes-rpc. In fact
this isn't stable part of the API and can be changed without prior
notice some day (until officially documented). But it will stay there
for now. And looking at 'proposal to move from /rw to /usr/local for new
Qubes developments' proposal on qubes-devel, most likely will eventually
become a stable API.

PPS We've considered thing exactly like this while designing VM
management. Here is (rather unreadable) picture:
https://github.com/QubesOS/qubes-issues/issues/1541#issuecomment-188697805
The service is the arrow at its left edge ;)

- -- 
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYWycPAAoJENuP0xzK19csKMkH/00wrCT8E6SOZnefbNT2M2Pm
Oh/2vt3Cd0w7BBQuRLWGbN4ESu5bIwzcczFqwOuKq7cR9AROcUOrEGwtKgdL3ro1
P0qLThbx8Eb10fO4LIbakVNKBO5wTTislg/kAnlZv08k8ctUXOXWs5vsRxeJvW9p
7+hygKZ4G8SxWpMfdskWhTNZq2F/V/N/A8sK4sEW1zp43V25uO+peRejM7m4bCUV
3QH0m+o4VDvwzOar6GMxKzm+zSYW9fyLZaCO/S9l5qWGoABjxMRI2qdHcf+SwU0q
DORixdm2G6vUtezJIYO3rM6IAXAj+OgDD0MJz3e9UwFtIZ5vnP87buJp5oBKAcw=
=Z8r3
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20161222010622.GZ1239%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Reply via email to