[RFC] Safe remote Dom0 terminals

116 views
Skip to first unread message

Jean-Philippe Ouellet

unread,
Nov 20, 2016, 7:20:42 PM11/20/16
to qubes-devel
Hello,

While trying to get graphics pass-through working, I found myself
needing to see the output of an interactive terminal on a remote
machine.

The general idea is to split the input and output paths, using your
same trusted keyboard input path as before, and sending only the
output over a unidirectional channel to a remote machine.

All escape sequences are passed as normal, preserving functionality of
interactive things (tmux, top, vim, etc.).

I have documented my approach [1], and opened a PR to add it to the
docs under the debugging section [2] so that we have a better way to
track specific suggestions / objections / etc.

Thoughts?

[1]: https://github.com/jpouellet/qubes-doc/blob/safe-remote-ttys/debugging/safe-remote-ttys.md
[2]: https://github.com/QubesOS/qubes-doc/pull/225

Marek Marczykowski-Górecki

unread,
Nov 21, 2016, 8:30:35 AM11/21/16
to Jean-Philippe Ouellet, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Nov 20, 2016 at 07:20:14PM -0500, Jean-Philippe Ouellet wrote:
> Hello,
>
> While trying to get graphics pass-through working, I found myself
> needing to see the output of an interactive terminal on a remote
> machine.
>
> The general idea is to split the input and output paths, using your
> same trusted keyboard input path as before, and sending only the
> output over a unidirectional channel to a remote machine.
>
> All escape sequences are passed as normal, preserving functionality of
> interactive things (tmux, top, vim, etc.).
>
> I have documented my approach [1], and opened a PR to add it to the
> docs under the debugging section [2] so that we have a better way to
> track specific suggestions / objections / etc.
>
> Thoughts?

As said on github: pretty smart approach! In principle looks good, but I
haven't tested it.
- --
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

iQEcBAEBCAAGBQJYMvb1AAoJENuP0xzK19cspVcH/iQcwfS8Lj5oH9G0okoeIT63
w0ETWo74zJZw8eyRNisjU9ahUaWbpa9w1Jze9YbXCfInXfqHtZKCBwZT5ZTASkPY
5/mNcNswq4lIcZAwLCmPMgfupRv4Myxq9cQiIq4H1S2jcOOd+5UGszgwCoSC2YJb
pQoQE0LHprWGndP4/tjsFm6KjYmMSR93hnEm8FM3720QC0D3N5Ph1QFp0qqCp7Ef
xG0AuvJM0nfLtQGMgrZrtC6YS6z5ZGibHJC4IljObgXsih3+/8/it3BETv8hR6uD
/Wl5jbebgv15J11LHacZJD4gy5we4I0EVPP82mwpyhaWlueIZ09k9FCw7f2hQLs=
=VyTG
-----END PGP SIGNATURE-----

Frédéric Pierret (fepitre)

unread,
Oct 16, 2017, 5:18:35 AM10/16/17
to qubes-devel
Hi,
I'm trying your method but I have trouble with it:

When I try the first (to a different VM), xterm appears well but when entering anything it stays blocked, like if there were no response. Do you have an idea?

Thank you

Jean-Philippe Ouellet

unread,
Oct 16, 2017, 1:04:46 PM10/16/17
to Frédéric Pierret (fepitre), qubes-devel
On Mon, Oct 16, 2017 at 2:18 AM, Frédéric Pierret (fepitre)
<epitre....@gmail.com> wrote:
> Hi,
> I'm trying your method but I have trouble with it:
>
> When I try the first (to a different VM), xterm appears well but when
> entering anything it stays blocked, like if there were no response. Do you
> have an idea?
>
> Thank you
> Le lundi 21 novembre 2016 01:20:42 UTC+1, Jean-Philippe Ouellet a écrit :

It sounds like you're probably just typing into the wrong terminal.

You're not supposed to type into the xterm that opens, that's just to
show you the output. You type into the original terminal you started
the script(1) session in. The stuff you type in the original terminal
should be mirrored to the 2nd one.

It's an intentionally unidirectional flow of information such that the
machine you display the output on (the machine with the new xterm
window) doesn't need to be trusted because it does not control
anything.

>> Hello,
>>
>> While trying to get graphics pass-through working, I found myself
>> needing to see the output of an interactive terminal on a remote
>> machine.
>>
>> The general idea is to split the input and output paths, using your
>> same trusted keyboard input path as before, and sending only the
>> output over a unidirectional channel to a remote machine.
>>
>> All escape sequences are passed as normal, preserving functionality of
>> interactive things (tmux, top, vim, etc.).
>>
>> I have documented my approach [1], and opened a PR to add it to the
>> docs under the debugging section [2] so that we have a better way to
>> track specific suggestions / objections / etc.
>>
>> Thoughts?
>>
>> [1]:
>> https://github.com/jpouellet/qubes-doc/blob/safe-remote-ttys/debugging/safe-remote-ttys.md
>> [2]: https://github.com/QubesOS/qubes-doc/pull/225
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-devel...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-devel/df3586b4-71e2-4dfa-8f1b-310f0c581e7d%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages