Share screen to AppVM

[deeplow]

The problem you're addressing (if any)

We all know the frustration of having to demo a project on one AppVM A but having our regular videoconferencing software in AppVM B. One has to install/start the software on the other one, making an overall bad experience. Sometimes even having to do this in a rush because we had forgotten about this "detail".

Describe the solution you'd like

Having an option to Share Screen to AppVM on AppVM A which would show as a virtual camera on AppVM B with the screen from A. Then on the videoconferencing software all the user would have to do is select that virtual camera to share the screen.

Where is the value to a user, and who might that user be?

The user is anyone who uses Qubes for doing live presentations.

Describe alternatives you've considered

• having to install videoconferencing software in the VM where the project is (which may be an offline VM)
• Having to move the project to demo onto videoconferencing AppVM and setting up the project environment
• Janky contraption to share dom0 screen (probably not the safest thing to do).

Additional context

• This may only be possible in Qubes R4.1 due to the slowness of Qubes RPC in R4.0

Relevant documentation you've consulted

• none

Related, non-duplicate issues

• [Contribution] qvm-screenshot-tool #953

[GWeck]

This might help to show Qubes itself in a videoconference. Currently the videoconferencing software runs only in an AppVM which sees only its own windows but - naturally - is not allowed to see the full screen. Running the videoconferencing software in dom0 is out of question, because this would require network access from dom0, which cannot be tolerated.

[deeplow]

Running the videoconferencing software in dom0 is out of question, because this would require network access from dom0, which cannot be tolerated.

Just edited the feature suggestion to be more explicit. Here the idea would not be to show dom0 itself, but instead to share one AppVM's screen with another AppVM.

[fepitre]

I can give you a tip for that. You can run a VNC server in the AppVM you want to share window and then you use this new DISPLAY to run application into. Then, in the other AppVM you qvm-connect-tcp to the vnc session port and use a viewer on the localhost port associated to the bind. If needed, I can (test) and write the whole guide.

[DemiMarie]

I can give you a tip for that. You can run a VNC server in the AppVM you want to share window and then you use this new DISPLAY to run application into. Then, in the other AppVM you qvm-connect-tcp to the vnc session port and use a viewer on the localhost port associated to the bind. If needed, I can (test) and write the whole guide.

Is this expected to be fast enough in practice?

[fepitre]

Is this expected to be fast enough in practice?

I think all your sentence is subject to subjective interpretation xD. More seriously, it works more or less pretty well on standard stuff. Streaming video could be a little bit less as smooth as in-VM.

[deeplow]

I can give you a tip for that. You can run a VNC server in the AppVM you want to share window and then you use this new DISPLAY to run application into. Then, in the other AppVM you qvm-connect-tcp to the vnc session port and use a viewer on the localhost port associated to the bind. If needed, I can (test) and write the whole guide.

Thanks for the suggestion @fepitre. That sounds doable. However, may take me a while to be able to do it. I suggested it more as a feature that could be useful for some and I think the community would be happy to have a guide. But I'd say it non-urgent. More one of those things that are just nice to have.

Thanks again!

[ghost]

I can give you a tip for that. You can run a VNC server in the AppVM you want to share window and then you use this new DISPLAY to run application into. Then, in the other AppVM you qvm-connect-tcp to the vnc session port and use a viewer on the localhost port associated to the bind. If needed, I can (test) and write the whole guide.

This approach works (was using it today), and isn't too hard to setup. @fepitre let me know if you want me to write the guide.

As for using an x11 screen as a webcam, this answer may be of some use to you https://superuser.com/questions/411897/using-desktop-as-fake-webcam-on-linux#713100 . I am not sure what additional steps would need to be taken in order to register the loopback webcam with qubes.

[ioleo]

@ctrlaltf24 I'd love to see a guide. Been wanting to seperate my conferencing from dev for a while now.

[ghost]

@ioleo @deeplow PR opened, let me know if any part is unclear.

[deeplow]

@ioleo @deeplow PR opened, let me know if any part is unclear.

Epic @ctrlaltf24! I've left some feedback there. It works well (albeit a bit strangely because it doesn't share the actual screen I use so I have to open things in a different :10 screen -- but can't complain too much).

I'll definitely will have to do a deeper reading on how VNC works and qubes-tcp-connect's security implications.

[ghost]

Epic @ctrlaltf24! I've left some feedback there.
Will take a look, thanks!
It works well (albeit a bit strangely because it doesn't share the actual screen I use so I have to open things in a different :10 screen -- but can't complain too much).

From a simplicity standpoint, it is easier to setup a new display (don't have to get any window ids/screen resolution and offsets), but entirely possible to share existing areas of your screen using x11vnc's (different vnc server) id pick (for window sharing), and -clip WxH+X+Y for existing monitor sharing. I can add a variant to the docs for that if you want.

I'll definitely will have to do a deeper reading on how VNC works and qubes-tcp-connect's security implications.
TL;DR; Better security than having both the presentation software (possibly semi-trusted like Teams/Slack/Discord/Matrix/Jitsi/ect) and your development VM in the same Qube, but worse than not connecting them at all.

By doing this you are trusting the VNC's isolation between host and view only guest. TCP security implications if you are binding an unfiltered port between two Qubes. If either of the two Qubes were compromised, it may be possible to exploit the vnc protocol to compromise the other Qube.

From what I understand about the ask option in qubes.ConnectTCP, we can be sure that we are notified whenever any new processes attempt to talk over that port. Just tested, and each new time a process attempts to communicate over the bound port, Qubes will re-prompt the target Qube.

[deeplow]

Thanks a lot for the clarifications!

but entirely possible to share existing areas of your screen using x11vnc's (different vnc server) id pick (for window sharing), and -clip WxH+X+Y for existing monitor sharing. I can add a variant to the docs for that if you want.

This would be amazing, if you have the time. I was looking into it myself yesterday, but didn't succeed with a few tries.

TL;DR; Better security than having both the presentation software (possibly semi-trusted like Teams/Slack/Discord/Matrix/Jitsi/ect) and your development VM in the same Qube, but worse than not connecting them at all.

Yep. That's very true!

[ghost]

This would be amazing, if you have the time. I was looking into it myself yesterday, but didn't succeed with a few tries.

I haven't had time to test yet, but the docs are written on the dev branch. I'll circle back in a couple days hopefully and test/add sensible flags to the vnc servers. https://github.com/ctrlaltf24/Contents/commit/2e5b69569c3719f52709bf8c5ed36a26e16e9aa5

[ghost]

@deeplow @ioleo PR merged https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/screen-share.md
I'm not sure how to get this new page to show up on the list here or if that is a job for maintainers to do if they see fit @andrewdavidwong

However, linking to external documentation from qubes-doc is perfectly fine. Indeed, the maintainers of the Qubes Community project regularly submit PRs against qubes-doc to add and update links in the table of contents pointing to Qubes Community pages.

• https://www.qubes-os.org/doc/doc-guidelines/

[andrewdavidwong]

@deeplow @ioleo PR merged https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/screen-share.md
I'm not sure how to get this new page to show up on the list here or if that is a job for maintainers to do if they see fit @andrewdavidwong

However, linking to external documentation from qubes-doc is perfectly fine. Indeed, the maintainers of the Qubes Community project regularly submit PRs against qubes-doc to add and update links in the table of contents pointing to Qubes Community pages.

• https://www.qubes-os.org/doc/doc-guidelines/

I've updated these instructions. Please take another look and see if that helps.

(FYI @marmarek, the need to add these external links means that the index can never be fully automated, but it should at least be possible for the non-external sections.)

[ghost]

Some research notes for if anyone ever comes back to this in the far future looking to implement webcam proxy/screen to webcam features:

I just stumbled upon a new feature of OBS (newer than the Debian build) that allows you to share an obs screen as a virtual webcam (using a kernel module called v4l2loopback).
Also looks like ffmpeg has support for outputting to video for linux 2 https://ffmpeg.org/ffmpeg-devices.html#v4l2

The VNC solution works just fine for the foreseeable future, however someday someone may want to implement this as a QoL improvement.

[ritschmaster]

I have found an interesting comment on Reddit which states how to run the idea of @ctrlaltf24.

[deeplow]

I have also used these instructions to configure remote VNC access to dom0 in a test system (ofc!). I wouldn't recommend this to anyone unless it's a purely a "for tests" installation. This can be useful for usability tests. I may document this somewhere at some point.

[ninavizz]

@deeplow Usability tests? Whaa, eh? (looks around in gleeful euphoria)

Open question in my noggin, though: @DemiMarie warned me against including any TCP policy actions in the GUI, as it presents highly non-trivial security implications. Like giving a toddler the futaba controller for a missile drone, as a play-toy.

That said, I have lost count of the number of people I know who've giggled and joked about eventually overcoming the inability to screenshare from Qubes—so I would LOVE to be able to somehow facilitate just screensharing in the Permissions Manager I'm creating for #4721.

Thoughts or ideas? TY Deeplow for sharing this with me from my Policy Manager thread in the Community, btw!

[DemiMarie]

Open question in my noggin, though: @DemiMarie warned me against including any TCP policy actions in the GUI, as it presents highly non-trivial security implications. Like giving a toddler the futaba controller for a missile drone, as a play-toy.

Elliot Killick has implemented safe screensharing in https://github.com/ElliotKillick/qubes-video-companion. I have tested it, and it works.

[ninavizz]

@DemiMarie It appears that Elliot has (ahem) "built" something awesome that I look forward to giving a try, myself! To factor this into the GUI I'm working on for #4721 though, it'd need to be packaged into Qubes OS as a native feature. Do you know if this is on Marek's radar, or of interest to the broader team to (waves hands in front of face to gesture official packaging things) include in a proper release?

Looking forward to having some fun giving that a spin, later this week! TY for sharing! :)