Copying between VMs from dom0

[wordsw...@gmail.com]

I want to copy network connection profiles from sys-net to sys-net-profiles as my computer shuts down.

I'm creating a bash script in dom0 to help with this.

I could use

qvm-run -ap sys-net "sudo qvm-copy-to-vm sys-net-profiles /etc/NetworkManager/system-connections/*"

...but that will spawn a dom0 confirmation dialogue that I'd rather avoid (after all, dom0 is initiating the copy).

I could "allow" qubes.Filecopy from sys-net -> sys-net-profiles, but I don't want to trust sys-net to initiate this copy on its own.

Is there any way to directly copy files from one VM to another, executed directly from dom0?

[qubenix]

wordsw...@gmail.com:

Not sure if it's the best solution, but this should work for avoiding
prompt (briefly tested):

for i in $(qvm-run -a -p -u root sys-net "ls
/etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root "cat
/etc/NetworkManager/system-connections/$i" > $i; qvm-move-to-vm
sys-net-profiles $i; done

--
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

[qubenix]

qubenix:

Oops small typo (forgot to name "sys-net" one time). Fixed:

for i in $(qvm-run -a -p -u root sys-net "ls
/etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root

sys-net "cat /etc/NetworkManager/system-connections/$i" > $i;

[wordsw...@gmail.com]

How much of a risk do you think this is, passing the file contents through dom0 via qvm-run -ap?

[qubenix]

wordsw...@gmail.com:

Yeah, this is moderately secure IMHO. You are copying everything from
/etc/NetworkManager/system-connections dir to dom0 before being moved to
destination vm without check. So theoretically something malicious could
be placed there. However, I don't see how it would be executed in dom0
(should the file be malicious). I took no consideration for security,
only to solve the problem of prompt.

--
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

[wordsw...@gmail.com]

Thanks, and point taken on not focusing on security implications.

I found a thread from last year where some third-party devs are concerned about the implications of letting qvm-run -p run wild:

https://github.com/SietsevanderMolen/i3-qubes/issues/15

It's a good idea, but I think I'm looking for a more secure solution - if it's out there.

[wordsw...@gmail.com]

>
> Thanks, and point taken on not focusing on security implications.
>
> I found a thread from last year where some third-party devs are concerned about the implications of letting qvm-run -p run wild:
>
> https://github.com/SietsevanderMolen/i3-qubes/issues/15
>
> It's a good idea, but I think I'm looking for a more secure solution - if it's out there.

I'm trying this for a solution:

- Creating sys-transfer-station VM
- Set it as internal VM (this VM will never be used for anything but transferring files)
- qubes.Filecopy policy: $anyvm sys-transfer-station allow
- As the computer shuts down, add to qubes.Filecopy policy: sys-transfer-station sys-net-profiles allow
- Transfer files
- Remove "sys-transfer-station sys-net-profiles allow"

I think this might do the trick... any comments on how this would be insecure? Seems somewhat similar to the qubes-dom0-update mechanism with sys-firewall.

[Chris Laprise]

On 06/28/2017 12:19 PM, wordsw...@gmail.com wrote:
> Thanks, and point taken on not focusing on security implications.
>
> I found a thread from last year where some third-party devs are concerned about the implications of letting qvm-run -p run wild:
>
> https://github.com/SietsevanderMolen/i3-qubes/issues/15
>
> It's a good idea, but I think I'm looking for a more secure solution - if it's out there.
>

IIUC, having dom0 parse the file list is whats worrying you? Otherwise,
passing data through dom0 (no parsing) should be considered secure.

You can have dom0 pipe between machines like so:
qvm-run -p sys-net "tar -cf - /etc/NetworkManager/system-connections" |
qvm-run -p sys-net-profiles "tar -xf -"

This entails a small amount of risk to the profiles VM (because tar file
is parsed there), but not to dom0.

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[cooloutac]

sys-firewall is considered trusted = green. sys-net is considered very untrusted and red alert. Maybe the most untrusted vm there is? besides dispvm? I guess it really depends on how paranoid you are. I doubt there are known exploits or examples we can come up and I'm just a noob but I would says as long as you are not copying anything from sys-net to dom0 you should be fine, don't care what command you're running.

[Vít Šesták]

It might be pointless to consider risks of passing result of qvm-run -p to dom0 Bash expansion when you have path traversal in the first place. When command «ls
/etc/NetworkManager/system-connections/» in sys-net returns paths like “../.bashrc ../../.bashrc ../../../.bashrc” and the cat command returns some arbitrary shell commands, you are close to be totally compromised by a malicious sys-net.

Regards,
Vít Šesták 'v6ak'

[wordsw...@gmail.com]

Thanks, you identified the problem more precisely than I would know how to.

[wordsw...@gmail.com]

So in this case, sys-net could return whatever malicious file it desired, it would be passed through dom0 one character at a time without absolutely no interpretation, ending up at the destination VM?

Or would dom0 collect the entire text of the file, and then pipe it in one piece to the destination VM?

[Chris Laprise]

Transfer through pipe is done by character or block, so no expansion or
parsing in dom0 in this case.

Another idea is to cat all the files together in a single file with a
special separator like '!!!! filename' between them. Then you can pipe
them without tar and use a text sanitizer on the receiving VM before
separating them.

[Vít Šesták]

I feel this to be controversial. It is right as long as you implement it carefully (How would you handle the separator being present in the content of the file? How would you sanitize the filenames? And so on…) AND you don't exceed the complexity of tar format.

Regards,
Vít Šesták 'v6ak'

[Chris Laprise]

A lot is implied once you're parsing on the receiving end. Can't be
avoided. Have to decide whether that "a lot" is better than tar's level
of complexity.

But I think its manageable; qvm-copy isn't too complex after all. I
think it passes the file size along with filename. That will nail-down
the separator issue, for example. Being aware of file syntax (special
purpose application) can help.

At the end of the day, maybe its better to trust tar, or not consider
dest VM security important, or re-use qvm-copy code for a utility that
works in a dom0-initiated mode.

[wordsw...@gmail.com]

For my uses, I would trust tar over my own ability to handle the sanitization.

As for potential compromise to the destination VM - all qvm-copy-to-vm should be done moving down the ladder of trustworthiness anyway, right? If this file were going to compromise the destination VM, then presumably it's come from a VM that is not trustworthy to begin with.