`qrexec-client-vm \$dispvm` loses stderr, while `qrexec-client-vm dispN` works fine

[rustybird]

Qubes OS version:

• R3.2
• Also R3.1 with QubesOS/qubes-core-agent-linux@b267e5c (otherwise this issue is not relevant to R3.1)

Affected TemplateVMs:

fedora-23

---

Using the following qubes.StderrTest RPC service:

#!/bin/sh
set -e

echo stderr okay >&2
echo stdout okay
xterm  # for convenience (does not make a difference)

If I run qrexec-client-vm \$dispvm qubes.StderrTest to launch a new dvm, the "stderr okay" message is missing.

But it is present, as it should be, for any other remote VM. Curiously, this works even for an explicitly named, already running dvm (e.g. disp12).

[marmarek]

This is caused by the way how DispVM is started in Qubes 3.x. Basically opening DispVM is a service call to dom0, then dom0 calls a service in newly created DispVM. And services called to dom0 do not return stderr, to not leak any sensitive data by mistake.
While it is possible to fix this, I'd say the fix is too intrusive to do it in stable release. But in Qubes 4.0 I think we can change this to be direct VM-VM connection.

[marmarek]

This is caused by the way how DispVM is started in Qubes 3.x. Basically opening DispVM is a service call to dom0, then dom0 calls a service in newly created DispVM. And services called to dom0 do not return stderr, to not leak any sensitive data by mistake.
While it is possible to fix this, I'd say the fix is too intrusive to do it in stable release. But in Qubes 4.0 I think we can change this to be direct VM-VM connection.

[rustybird]

Is there by any chance a workaround if stderr is supposed to end up in dom0 anyway? I'm (essentially) doing the following in dom0 for split dm-crypt:

outer_dvm=$(qfile-daemon-dvm LAUNCH dom0 '' red)
...
qvm-run --pass-io "$outer_dvm" 'qrexec-client-vm \$dispvm getKeyFromLuksHeader <header >key'

So the outer dvm receives the dm-crypt key from the inner dvm, while dom0 is supposed to see the inner dvm's cryptsetup prompts etc. on stderr as they happen.

[rustybird]

Is there by any chance a workaround if stderr is supposed to end up in dom0 anyway? I'm (essentially) doing the following in dom0 for split dm-crypt:

outer_dvm=$(qfile-daemon-dvm LAUNCH dom0 '' red)
...
qvm-run --pass-io "$outer_dvm" 'qrexec-client-vm \$dispvm getKeyFromLuksHeader <header >key'

So the outer dvm receives the dm-crypt key from the inner dvm, while dom0 is supposed to see the inner dvm's cryptsetup prompts etc. on stderr as they happen.

[marmarek]

If you're doing it from dom0 anyway, you can split the operation into steps:

qvm-run --pass-io "$outer_dvm" 'cat header' | qfile-daemon-dvm getKeyFromLuksHeader $outer_dvm '' red | qvm-run --pass-io "$outer_dvm" 'cat > key'

[marmarek]

If you're doing it from dom0 anyway, you can split the operation into steps:

qvm-run --pass-io "$outer_dvm" 'cat header' | qfile-daemon-dvm getKeyFromLuksHeader $outer_dvm '' red | qvm-run --pass-io "$outer_dvm" 'cat > key'

[rustybird]

Thanks, that's probably the sanest way.

[rustybird]

Thanks, that's probably the sanest way.

[marmarek]

Done (for Qubes 4.0)

[marmarek]

Done (for Qubes 4.0)