How to pass standard input securely from dom0 to qubes?

User Support
1

Hey,

I want to pass standard input securely from dom0 to domU (specific qubes). One possibility:

qvm-run -p my-qube "cat - > ~/local/path/file" < /some/file

But -p can inherently be dangerous. Since dom0 also receives standard input from domU , it opens a potential attack vector for dom0:

–pass-io, -p pass stdio from remote program

Is there a way to enforce only one-way-passing of input in direction to less-privledges qubes in domU (dom0 → domU)?

I could do something like:

qvm-run -p my-qube "cat - > ~/local/path/file" < /some/file > /dev/null

Is that as secure as not passing -p at all, cause any shell/terminal interpreting of qube input in dom0 is prevented by throwing it away?

Still I have to remember this every time. One one is perfect, mistakes will happen…

PS: Passing a file as standard input is only an example. It might as well be some code snippet via here doc.

2

qvm-run -p my-qube “cat - > ~/local/path/file” < /some/file > /dev/null

should be the best you can get.

But yes, I also still think that qrexec should support one-way transfers.
However it was unfortunately designed inherently bidirectional and that is not going away any time soon.

1 Like
3

Thanks @tripleh !

This is a little bit sad to hear, but the hint about qrexec architecture is interesting.

I would love to trigger batch installations from dom0 via stdin, but don’t want risk any corruptions by passing IO (can’t make assumptions about qube’s state).

Probably best workaround for me is to wrap standard input in a file and copy to destnation qube via qvm-copy-to-vm.

4

I think it’s better to do it with salt:

You can read about it more by searching on this forum and you can also take a look at these notes:

5

Yes, salt is generally the Qubes way to do it.

Internally it probably also uses the bidirectional qrexec channel though. IIRC dom0 <–> default-mgmt-dvm instance <–> target VM for salt.

Honestly I’m not too worried about the security concerns wrt bidirectional qrexec for dom0 (<)–> appVM as it “just” requires dom0 to mostly ignore or sanitize untrusted incoming data. That requires some thinking on the programmer’s end (which is suboptimal / more error prone), but I guess was mostly done by the Qubes devs.

The qrexec bidirectional nature is more interesting when it comes to side channel attacks. Imagine two VMs with different content, both compromised and attempting to communicate with each other. They can use any qrexec call between them to establish a > 100 MB/s “side” channel.