Qubes OS screensharing

[13940143097109234781094378143814]

Hello,

is there some technology to share screens between two Qubes OS PCs on different location.

How screensharing will fit to the Qubes OS VM-logic?

Should be the screensharing window to window or VM to VM?

Kind Regards

[Vít Šesták]

Not sure if screensharing will work on seamless Linux PVMs. I was unable even to make some internal VM screenshot. (I can make a screenshot, but it is just a single color.)

I have tried to run Openbox in order to make it working. Openbox can be run in the VM (and it looks rather funny…), but it does not solve the screenshot issue. Without solving screenshots, I doubt that you will find a screensharing solution that works.

But I've just tried Debian. You might be lucky with Fedora, which seems to have some different X11 setup in multiple ways.

Note that even if you manage to have screensharing working, the screens will be probably shared without window borders and you might share also some content of inactive windows, even if they are not visible for you.

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

[Jeremias E.]

Hello,

what kind of screen sharing to you want to do?

There are multiple options:
1. Do you want to access remotely your dom0 on PC A from PC B?
2. Do you want to access a VM on PC A from PC B?

or maybe some other configurations?

@Vít Šesták 'v6ak' I always use the Ksnapshoot tool to make screenshot. They are saved on dom0.
Than I copy the screenshot from dom0 to the VM I want to work with the screenshot.

Best regards
  J. Eppler

[Vít Šesták]

In my case, I want to share desktop of one VM. I see no other way than using a HVM. Unfortunately, HVMs don't implement sound, so I can't share the desktop and talk using the same VM. (There are some funny workarounds possible like using extra VM for sound or using some completely external device for sound. Marek says that assigning the sound card is another workaround (with obvious drawbacks), but you need VT-d if you want to do that with HVM.)

It would be great if non-seamless mode is supported on PVMs…

Yes, I know that screenshot tools can be used in dom0 and I use that sometimes. In my case, screenshot tools are there just for testing if the screen seems to be capturable within the VM. If screenshot tool does not work, any screensharing tool will unlikely work.

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

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Sep 30, 2015 at 12:10:52PM -0700, Vít Šesták wrote:
> In my case, I want to share desktop of one VM. I see no other way than
> using a HVM. Unfortunately, HVMs don't implement sound, so I can't share
> the desktop and talk using the same VM. (There are some funny workarounds
> possible like using extra VM for sound or using some completely external
> device for sound. Marek says that assigning the sound card is another
> workaround (with obvious drawbacks), but you need VT-d if you want to do
> that with HVM.)
>
> It would be great if non-seamless mode is supported on PVMs…

You can try running VNC server (or any other virtual X server).
It seems that "dummy" driver used in the VM have some missing
functionality which prevents screen captures. But using some virtual X
server should workaround this problem.

Something like this:
1. sudo yum install tigervnc-server
2. vncpasswd
3. vncserver
4. vncviewer :1 &
4. export DISPLAY=:1 (still from the same terminal)

Now every command started from this terminal will be started in virtual
X server. You'll probably want to start with something like
"gnome-session &".

Pretty ugly solution, but it works :)

- --
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 v1

iQEcBAEBCAAGBQJWDDm5AAoJENuP0xzK19cs0nsH/0fHqf6kEM+9jytKLrH5SLDO
GYgmcFB3TNPdm2maCfdw6GZ7MweXysX+tJZeeUG64ZnRCENAaikfkoWG6idhmCng
bTqEe23VtIpIChCj/Ls5tdwsQzIpsjcvW98aDEbHdG+RCKL+e8i9PRv1rK5P5KTB
4YF6QuY+jdXuRh1wdjCazkfsWWfwxIsTe6CbvrGe+LQcYRX+M5KScBbShVRt/S1L
eQ6mkE1GPizRh2hrC9Lh+IV7O9Wdtjp1vwreGuaY10yTrvUQwP7IXEDNFunLI+qO
QTGdvyi5UKBxCufWwu3ASQUBCGa0m7+oWU6rsuvu1OKs9fL5a3pH6BwBbrIHGZc=
=va0C
-----END PGP SIGNATURE-----

[Vít Šesták]

Great! This seems to be a viable solution and more comfortable than using a separate HVM for that.

Some fine-tuning and Debian adaptation (someone might find that useful):

On Debian, there is no TigerVNC in repository, but if you don't want to add a new repository, you can use TightVNC, that seems to be the prececessor of TigerVNC and is very similar.

The VNC viewer seems to require password in my case (maybe this is a difference between TightVNC and TigerVNC), so the following is better: vncviewer :1 -passwd ~/.vnc/passwd&

It is a good idea to pass geometry to VNC server, e.g.: vncserver -geometry 1600x900

It might be also a good idea to use fullscreen for VNC window: Kwin: Alt+Space(???), More Actions, Full screen; I am not 100% sure if Alt+Space is the default keybinding in Kwin. I have also configured a keybinding for fullscreen.

When I run Openbox as a window manager, I can also use keyboard shortcuts that are ambigious with Kwin, but I am not sure how much universal this advice is. For example, Alt+WinLeft+Tab is not handled by Kwin in dom0, but it is handled by Openbox in the AppVM as Alt+Tab. The same applies to Alt+WinLeft+Space, which is handled as Alt+Space in AppVM. BTW, these hacks work also for Windows HVMs, but this is off-topic there.
However, I am not sure if this would work without having Win+Tab shortcut in dom0. I am also not sure about other VMs (either in dom0 or in an AppVM) how they handle such situation.

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

[Vít Šesták]

Hmm, but if some software complains about missing Xrandr, then using TigerVNC over TightVNC might be the solution… The installation of TigerVNC in Debian is not too hard, even the manual one.

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

[Dave C]

I hope no one minds reviving an old thread...

I recently needed to screenshare in Qubes (4.x, but 3.2 should work the same). I wrote up my notes:

https://www.dave-cohen.com/blog/qubes-vnc-screenshare/

Feedback welcome, especially if the method can be improved. Thanks.

[Nuno Branco]

I was under the impression that 4.0, by virtue of running on HVM, would
allow for native screensharing (webex, zoom, skype, etc) by simply
disabling seamless mode on the VM you want to share - is this not the case ?

--

Best regards,
Nuno Branco

[Vít Šesták]

Dave, why you start a new VM and not just use a loopback? Is the reason sharing apps from multiple VMs? If si, you are at least significantly weakening isolation. Maybe you are not keeping any, not sure. X11 was not designed for isolation at all.

Nuno, this is probably possible, but not so trivial. You would need Grub (as HVMs and PVs have different boot mechanisms) and you would need to adjust some things made for PVs - probably some startup services and some X11 config files. Those changes (especially the Grub change) would require a modification of the template. And you would also need to reboot to change it.

I have some idea for full screensharing (considering Qubes-agnostic generic screensharing apps):

1. Scrap the screen in dom0 and send it to a VM through Qubes RPC. It seems that VLC can be used for that. Uncompressed video could be ideal for low latency and lower CPU usage. Compression does not make much sense within a physical computer. But compressed video could be also acceptable. I believe video encoding is not a risky operation, so it can be done in dom0 without any additional real risk.
2. In the VM, play the video in a VNC-loopback X11 session.
3. Run the screensharing app of your choice in the same X11 session.
4. Make the screensharing video fullscreen.

Of course, this would make some fractal effect when the VNC client is visible on screen ☺

I haven't tried it yet, but it seems

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

[Dave C]

On Thursday, January 25, 2018 at 1:34:03 AM UTC-8, Vít Šesták wrote:
> Dave, why you start a new VM and not just use a loopback? Is the reason sharing apps from multiple VMs? If si, you are at least significantly weakening isolation. Maybe you are not keeping any, not sure. X11 was not designed for isolation at all.

I run the vncserver in a new VM so that I can screenshare from...

* multiple app VMs
* VMs that can't access the conference site (i.e. bluejeans.com) or can't access the net at all
* VMs that don't have vncserver installed, or don't have a plugin needed to screenshare

My approach lowers security while screensharing. But the rest of the time, not screensharing, the VMs are running with normal firewall settings.

I realize X11 is a weak link in what might be an otherwise secure desktop. One of the reasons I am a fan of Qubes!

[Vít Šesták]

On January 27, 2018 7:57:02 AM GMT+01:00, Dave C <qu...@dave-cohen.com> wrote:
>* VMs that can't access the conference site (i.e. bluejeans.com) or
>can't access the net at all

How can a VM without network access open a window in the X11 accessible from network?

>* VMs that don't have vncserver installed, or don't have a plugin
>needed to screenshare

IMHO a minor gain.

>My approach lowers security while screensharing. But the rest of the
>time, not screensharing, the VMs are running with normal firewall
>settings.

It is likely that a VM can infect any other of the VMs (or the screensharing VM). There are multiple potential ways to do so:

a. Exploit some vulnerability in X11 protocol implementation.
b. Open a terminal (if not already opened) and type a command. This is possible, because any client can inject any input events to other client.
c. Download some file using webbrowser and run/install it (e.g., using some packaging system).
d. I remember I have read that X11 effectively provides no isolation between apps and I had an impression that any app can by design even run some code in another client. However, don't take this point as verified unless you verify it from some other source.

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

General note: Maybe top-posting is bad. However, quoting whole message (including quotes of quotes and quotes of quotes of quotes etc.) before your message is even worse. Please don't let others scroll extensively.

[Dave C]

On Sunday, January 28, 2018 at 12:24:08 PM UTC-8, Vít Šesták wrote:

> On January 27, 2018 7:57:02 AM GMT+01:00, Dave C wrote:
> >* VMs that can't access the conference site (i.e. bluejeans.com) or
> >can't access the net at all
>
> How can a VM without network access open a window in the X11 accessible from network?

Indeed, I stand corrected. This point could apply to a restrictive firewall, but the VM would need to network with the local VM running vncserver.

[snip]

>
> >My approach lowers security while screensharing. But the rest of the
> >time, not screensharing, the VMs are running with normal firewall
> >settings.
>
> It is likely that a VM can infect any other of the VMs (or the screensharing VM). There are multiple potential ways to do so:
>
> a. Exploit some vulnerability in X11 protocol implementation.
> b. Open a terminal (if not already opened) and type a command. This is possible, because any client can inject any input events to other client.

I can imagine opening a terminal in the VM running vncserver and the window manager. Could attacker open a terminal in other vm that has opened some application in that display? (Application that is not a terminal, I mean. I do see how an attacker could use any application shown in the display.)

> c. Download some file using webbrowser and run/install it (e.g., using some packaging system).
> d. I remember I have read that X11 effectively provides no isolation between apps and I had an impression that any app can by design even run some code in another client. However, don't take this point as verified unless you verify it from some other source.

You make some great points. Thanks. I'm re-thinking my approach.

-Dave

[Vít Šesták]

On February 1, 2018 6:42:08 PM GMT+01:00, Dave C <qu...@dave-cohen.com> wrote:
>Indeed, I stand corrected. This point could apply to a restrictive
>firewall, but the VM would need to network with the local VM running
>vncserver.

BTW, you could also pipe the network communication through qrexec. This could be more secure than restrictive firewall.

>I can imagine opening a terminal in the VM running vncserver and the
>window manager. Could attacker open a terminal in other vm that has
>opened some application in that display? (Application that is not a
>terminal, I mean. I do see how an attacker could use any application
>shown in the display.)

It depends on what application you mean. I can see how a webbrowser can be used as a gadget to open terminal and some other applications (e.g., Libreoffice) can be used to open webbrowser. (And maybe LibreOffice supports macros or something similar, so attacker does not need to browser/terminal. Also, a text editor like Geany can be abused for editing files like .bashrc.

I am not sure about generic applications with no such option of saving files and opening them in some apps. I remember statements that X11 is not designed for isolation and some those statements look like this is possible generally by design. I was able to neither confirm nor deny it in a short time.

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

[Vít Šesták]

I've implemented my approach of screensharing. It pipes content scrapped from dom0 to a VM. I don't call it a success, because the FPS is terribly low. But maybe someone can try to get it even further.

Recording:
* VLC and ffmpeg could be good choices (with probably many options for adjusting it for your needs), but they aren't available in Fedora unless you use some third-party repository, which is not what I wanted.
* recordMyDesktop works with some hacks and config, but its FPS is terribly low (at least when using --on-the-fly-encoding). It also does not have much encoding options. It would be probably ideal to use uncompressed video, because transfer is cheap and encoding/decoding is GPU/CPU-intensive. (Actually, GPU can at least theoretically help with encoding, as it happens in dom0. It can't help with video decoding.) I haven't tried to adjust video quality, because I am not sure about the effect on encoding performance.
* Not sure about other alternatives available in Fedora without additional repositories. I am not aware about any.
* Maybe we could try the software intended to pipe windows from domUs to dom0 for the other way?

Playback:

* I use MPlayer, but any player capable of playing a pipe can do the job.
* If you want to use it in a VNC session, you will probably want to add something like “env DISPLAY=:1”. But now, it is too early.
* In my experiment, the domU part was Debian 9, but I don't think this matters much.

The script with comments: https://gist.github.com/v6ak/1678244cd71a0ebd019531d02a149c8f

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

[Vít Šesták]

Just another idea: Since the video approach is sooo slow, I've tried another approach. This one is suboptimal by design, but it is much faster than the recordMyDesktop variant. This one requires a VNC loopback session or other way of getting another session with its own background. (This is something that would be required for real screensharing anyway.) You can easily get it by apt install tigervnc-standalone-server tigervnc-viewer openbox (or similar command on non-Debian system), running vncpasswd (configure any password, you don't have to remember it), running tigervncserver and then running the viewer command mentioned it server's output.

There is my hack. It assumes that:
* /tmp/out.bmp is a symlink to /dev/stdout. The reason is the same as with the video approach.
* You have scrot installed in dom0.
* You have feh installed in the target VM.
* Your VNC loopback session has display :1. (You can change it.)
* You want to pipe it to disp3. (You can change it.)

The command to run in dom0:

while true; do (scrot /tmp/out.bmp | qvm-run disp3 -p 'env DISPLAY=:1 feh --bg-center --no-fehbg -'); done

It is suboptimal for many reasons:

* It forks several processes in both dom0 and domU for each screenshot.
* It opens a new RPC call for each frame. (Which causes previous unoptimality.)
* All screenshots are saved in /tmp (internal behavior of feh). This probably matters less when /tmp is tmpfs, but still.
* Works fully synchronously.

Actual performance on my laptop was about 2 FPS (measured by my eyes), which is not great, but it works much better than the video. For some purposes, 2FPs might be useable. Not sure why this is better than the video, maybe it is due to missing compression and decompression, maybe it is due to missing buffering.

How the performance can be improved:

1. Use a single pipe, don't open a new RPC call for each frame. (This might get tricky due to buffering. It might be important to verify that it works well even if the consumer is slower than producer.)
2. Use a single process as producer instead of looped scrot.
3. Use a single process as consumer instead of looped feh.

Another idea is to use half-duplex VNC, but this might be also tricky. The goal is not to allow to pass any input from the untrusted VM to VNC server in dom0, maybe except information about potential congestion (i.e., situation when consumer is slower than producer). I am not sure if VNC is designed for that, but Wireshark capture of session with -ViewOnly on client-side looks still a bit chatty. There are many Authentication Response messages for some time (WTF?) and many Fence messages (hmm, probably synchronization).

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

[Vít Šesták]

I am sorry for the monolog, but I have some further ideas and findings.

I see two promising options to make screensharing great again:

a. VM screensharing: It would share the screen of the current VM and nothing else. We need to get in-VM screenshots working for this. Or you can use a VNC loopback session with its drawbacks.
b. Full screensharing. This requires to pipe screen contents from dom0 to a specific domU. Maybe we need to stream it to some window that cover everything while being ignored by qubes-gui.

Technical findings:

When considering the most common VMs in Qubes, none of those two variants currently works well. When I try to screenshot the main X11 of a PV domU, I get a solid white image. This is true for any screenscrapping technique I have tried. I am not sure what is the reason of white screenshot, but I've traced it a bit:

* The color is not related to xsetroot call in /usr/bin/qubes-session (i.e., you can change it to some other color in a StandaloneVM and reboot it, but you will still get white screenshot).
* It is not related to xorg.conf and/or the dummyqbs driver. First, changing “dummyqbs” to “dummy” does not help. Second, when I copy /etc/X11/xorg-qubes.conf to /etc/X11/xorg.conf run a second X11 session (as :1) and screenshot it (e.g., env DISPLAY=:1 scrot out.png && feh out.png), the screenshot works. (Maybe you will want to run something there to see it, e.g., env DISPLAY=:1 xterm&.)
* It is not related to window manager. When i run a WM (Openbox) in standard Qubes session, it does not help. I believe it is also true vice versa.
* It seems to be related to qubes-gui process. When I kill it, screenshots (and thus screensharing) starts working. But obviously, you cannot interact with the GUI.

You can see it on a simple experiment. I've used two sessions of a DVM started by command qvm-run '$dispvm' bash. This creates some inconvenient Bash session (e.g., you cannot see prompts and error messages), but it is good enough to run few commands as follows:

sudo apt install scrot # Install screenshoting app. Adjust this if you are not on Debian.
xterm& # run some app that will be seen on screenshot
# sudo killall qubes-gui # Run this in one VM only in order to see differences.
ps aux | grep qubes-gui # See if it is killed
(rm -f out.png && scrot out.png && cat out.png | qvm-run '$dispvm' 'feh -') 2>&1 # Look at the result. Since the VM might be incapable of showing some GUI, I start a new VM.

You might need to adjust the commands or your environment a bit (e.g., install feh if not installed), but it should be trivial and obvious.

I do not know why qubes-gui makes such difference. The source is at https://github.com/QubesOS/qubes-gui-agent-linux/blob/master/gui-agent/vmside.c , but I still don't know why it behaves this way. There are two occurrences of “white” (case-insensitive), but I don't understand the code much. But I have found some interesting part: “/* pretend that GUI agent is window manager */”. So, it tries to look like some window manager. This is strange, as Openbox does not complain that some WM is already running when I run it within a Qubes session. But I don't understand X11 details much, which is probably the reason I don't understand the linked source code much.

No, I don't have a solution. I have few intermediate results that might be useful for someone to find something more.

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

[donoban]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/11/2018 04:03 PM, Vít Šesták wrote:
> I am sorry for the monolog, but I have some further ideas and
> findings.

Hehe, I'm following your progress but I don't have currently the need
of share my screen.

I enjoy reading it and maybe I will test when I have some free time
for spend on it :)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlqAXpoACgkQFBMQ2OPt
CKW+AQ/9HGkyV9vb/SupPzaxu/wDQQmDoCRlFMYqF5YMyLQzh721m0dOGIqyJiUS
0968aRoeLPAnj+kBXlTxeUIH7r6CGpkhsrFdoAZVLPX5iTZ/8T16p8kXE5wRKG0W
POhYma3Wp8F0S9VOB8Duco+xyahpy8oB2jRFFuYDAhVG3v9NniOwzPwhgclJu0oo
wj3dLDkCaBz19BCZHe7dhBnjoKxPXQW4j5NXi6dtNgcWNpSxNKDlpXMs2ovVSR2d
M3lzctOzGel8fKRxQXAf3TFibOVmIF2V7bXqcGbhKfo3QY0YaC3tqjHf8HUVsh41
NkTRi7RGQbuYQ4DXMnVxLSzhaA7cF7lIa375vx7RSPXLmlvxPwaM5WlCDICYZauN
u2w2l6GzDIyCUG4V7Ei1zuGYQLBHo5bFpOhjbc0hXoeHXCDDPgJIOKawiA43Gqbb
SLWvika6Wbs4sTfYNsFZY1jBi1a8DvOOkI7wWrqu4uxX5iTRdnMJl6jIH13iChql
yvuWbqgN7b8/mzNgsoEY8s4P1YDvAa4o7JLjPJqtaOoJzLhjtAidAPq6Cb9FwRYg
KfyAdq5R4GNRAshYiZcsO/SC1r5g1DB+v0pf8Q71+dux6fkMgobyjljuO4eTv0wY
MxhV7eyTBjKzbkneddB81DReQPGI/QFXxz09fwNe+HCitpv6pg8=
=+c3d
-----END PGP SIGNATURE-----

[Vít Šesták]

Marmarek has identified the issue and fixed it: https://github.com/QubesOS/qubes-issues/issues/4351

So if you are patient, you can just wait until you see it in current repository. (There will be likely Gihtub comment.)

If you are eager, you can wait until it is in testing repository. (Again, we will probably see a Github comment.)

If you are supereager, you can compile it yourself 😉

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

[Dave C]

On Thursday, October 18, 2018 at 5:52:31 AM UTC-7, Vít Šesták wrote:
> Marmarek has identified the issue and fixed it: https://github.com/QubesOS/qubes-issues/issues/4351
>

I haven't been vocal on this thread in a while... but I appreciate the comments from v6ak and the bugfix from Marmarek.

I had a moment to update my blog post about screensharing in Qubes: https://www.dave-cohen.com/blog/qubes-vnc-screenshare/, please check it out if interested. I welcome any constructive feedback.

Cheers, -Dave

[Fernando]

The fix from Marmarek worked for me as soon as it was released, but then after a few updates (I don't remember exactly when) it stopped working for me.

Do you have any suggestions on where I can start looking to debug this issue? From what I see, no one else has reported problems.

Thanks,

Nando.

[brenda...@gmail.com]

On Thursday, April 25, 2019 at 1:54:38 PM UTC-4, Fernando wrote:
> The fix from Marmarek worked for me as soon as it was released, but then after a few updates (I don't remember exactly when) it stopped working for me.
>
> Do you have any suggestions on where I can start looking to debug this issue? From what I see, no one else has reported problems.

Is release repo up to date with the related changes from testing?

I'm using testing and it worked on and off recently, but worked ok the last two attempts. Hard to pin down, though, as I'm updating dom0 daily-ish.

Just tried a few device attach/detach/attach/VM restart/VM start/attach of an ISOstick with -testing updates and it seems to be working today...

Brendan

[Fernando]

Thanks, Brendan. At least I know it's not just my local config.

I'm not using testing repo since I need my work laptop to be quite stable, and I run weekly updates in dom0. That would explain why it consistently doesn't work for me.

I guess I'll just have to wait for it to become stable.

Nando.