config-vm and inter vm file transfer
45 views
Skip to first unread message
john.david.r.smith
Dec 21, 2016, 12:35:50 PM12/21/16
to qubes-users
hi.
currently i am configuring salt to create and configure all my vms.
my target is to have only a minimal set of vms i need to backup (vault,
config, data, custom systemd based services for my vms) and a set of
salt files to create my whole setup.
creating vms and installing software works.
but for some vms i need additional config data (ssh-keys, openvpn-config
file, etc).
I want to store this data in the config vm.
now i need to get the config data for each vm from my config-vm.
i have multiple ideas, but i am not satisfied with any:
1) run `qvm-copy-to-vm` in config-vm + run some copy commands in the
target-vm
2) get the file to dom0 via `qvm-run --pass-io "cat ...." >
file_in_dom_0` + transfer the file to the targetvm
3) use managed file from salt
why i don't like the solutions:
1) needs user interaction to allow the transaction or i need to allow
all file transfers from my config-vm.
i like neither of these options.
additionally i need to to issue two commands.
2) i don't like the part about transferring anything to dom0.
also it would be difficult to handle directories.
3) i would transfer the files to dom0 (i don't want to do this)
I am currently searching for a nice way to solve all of this.
I have an idea but it would require some new functionality (at leas i
think so).
in my config-vm i have multiple config folders for each target property
(e.g. autoshutdown, QubesOutgoing for my own services).
each folder contains files to copy to /rw)
in dom0 i would run something like this
`qvm-inter-vm-copy config-vm:~/autoshutdown/* some-template:/rw/`
this command would copy all files/directories from ~/autoshutdown/ in
config-vm to /rw in some-template.
the command qvm-inter-vm-copy would only be available in dom0, so it
would not need additional user interaction.
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?
-john
currently i am configuring salt to create and configure all my vms.
my target is to have only a minimal set of vms i need to backup (vault,
config, data, custom systemd based services for my vms) and a set of
salt files to create my whole setup.
creating vms and installing software works.
but for some vms i need additional config data (ssh-keys, openvpn-config
file, etc).
I want to store this data in the config vm.
now i need to get the config data for each vm from my config-vm.
i have multiple ideas, but i am not satisfied with any:
1) run `qvm-copy-to-vm` in config-vm + run some copy commands in the
target-vm
2) get the file to dom0 via `qvm-run --pass-io "cat ...." >
file_in_dom_0` + transfer the file to the targetvm
3) use managed file from salt
why i don't like the solutions:
1) needs user interaction to allow the transaction or i need to allow
all file transfers from my config-vm.
i like neither of these options.
additionally i need to to issue two commands.
2) i don't like the part about transferring anything to dom0.
also it would be difficult to handle directories.
3) i would transfer the files to dom0 (i don't want to do this)
I am currently searching for a nice way to solve all of this.
I have an idea but it would require some new functionality (at leas i
think so).
in my config-vm i have multiple config folders for each target property
(e.g. autoshutdown, QubesOutgoing for my own services).
each folder contains files to copy to /rw)
in dom0 i would run something like this
`qvm-inter-vm-copy config-vm:~/autoshutdown/* some-template:/rw/`
this command would copy all files/directories from ~/autoshutdown/ in
config-vm to /rw in some-template.
the command qvm-inter-vm-copy would only be available in dom0, so it
would not need additional user interaction.
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?
-john
Unman
Dec 21, 2016, 6:46:03 PM12/21/16
to john.david.r.smith, qubes-users
A short script that writes to the policy file allowing FileCopy from
config-vm to targets.
qvm-run config-vm 'qvm-copy-to-vm target Dir'
Remove permissive rule from policy file
qvm-run target 'mv .....'
salt
Marek Marczykowski-Górecki
Dec 21, 2016, 8:06:28 PM12/21/16
to john.david.r.smith, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Wed, Dec 21, 2016 at 05:35:37PM +0000, john.david.r.smith wrote:
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-----
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:
> (the functionality (intervm copy) should mostly already be there).
>
> Or is there some other/better way?
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-----
Reply all
Reply to author
Forward
0 new messages