Screen recorder for Qubes..?

[neilh...@gmail.com]

I see that dom0 has a screenshot tool, but how about a screen recorder tool..?

I.e. one that would record video.

Sound is not needed, but I certainly need to record many screenshots per second.. Many frames per second.

Thanks

[Grzesiek Chodzicki]

In order to capture the whole screen such tool would need to run in dom0 which is really, really not a good idea. Is an external capture card an option here?

[Jean-Philippe Ouellet]

On Mon, Nov 7, 2016 at 2:02 PM, Grzesiek Chodzicki
<grzegorz....@gmail.com> wrote:
> In order to capture the whole screen such tool would need to run in dom0 which is really, really not a good idea.

I think it is important to understand the actual risks involved,
rather than just saying something is "really, really not a good idea".

The design of qubes allows things of arbitrary complexity to exist and
operate in dom0, so long as they do not handle untrusted inputs, and
the tool itself is not actively malicious against qubes.

In this case, the only untrusted inputs to a screen-recording tool
should be only the framebuffer that it is recording. In this case, for
an attacker to be able to violate the qubes security model, they would
need to find an exploit in the video compression codec, and trigger
that from the thing you are recording.

For many, this may be an acceptably unlikely risk, particularly if the
thing you are recording is relatively trusted already.

[Chris Laprise]

On 11/07/2016 02:11 PM, Jean-Philippe Ouellet wrote:
> On Mon, Nov 7, 2016 at 2:02 PM, Grzesiek Chodzicki
> <grzegorz....@gmail.com> wrote:
>> In order to capture the whole screen such tool would need to run in dom0 which is really, really not a good idea.
> I think it is important to understand the actual risks involved,
> rather than just saying something is "really, really not a good idea".
>
> The design of qubes allows things of arbitrary complexity to exist and
> operate in dom0, so long as they do not handle untrusted inputs, and
> the tool itself is not actively malicious against qubes.

That's a great way to describe it.

> In this case, the only untrusted inputs to a screen-recording tool
> should be only the framebuffer that it is recording.

The framebuffer is being handled by the trusted dom0 graphics stack, so
is actually a trusted input.

> In this case, for
> an attacker to be able to violate the qubes security model, they would
> need to find an exploit in the video compression codec, and trigger
> that from the thing you are recording.

Even if such a thing were feasible (keeping in mind this is not
decompression), its probably hypothetical because its a simple matter to
pipe the raw video to a codec in an appVM.

>
> For many, this may be an acceptably unlikely risk, particularly if the
> thing you are recording is relatively trusted already.
>

The threat model is pretty similar to Qubes' Trusted PDF feature.

Chris

[neilh...@gmail.com]

None of this makes any sense to me.

There is already a screenshot tool

This would just be multiple screenshots per second.

I don't see why it isn't possible

[Chris Laprise]

Yet, you don't see people on regular Linux or Windows making videos of
their desktop using the usual static screenshot tool. It has to be
efficient enough to capture fluid motion.

Maybe the new Qubes screenshot tool can be adapted for video, if it
isn't already.

Chris

[Jean-Philippe Ouellet]

On Mon, Nov 7, 2016 at 2:29 PM, Chris Laprise <tas...@openmailbox.org> wrote:
> The framebuffer is being handled by the trusted dom0 graphics stack, so is
> actually a trusted input.

Perhaps we have run into trusted != trustworthy terminology issues.

I meant to say that the content of the framebuffer being processed by
the highly complex [1] compression algorithms is directly
attacker-controlled, and thus attacking dom0 by displaying specially
crafted bitmaps is a theoretical attack vector.

[1]: https://sidbala.com/h-264-is-magic/ (from recent hacker news --
serves to illustrate that video compression has significant
complexity, and it is not impossible to imagine the existence of
exploitable edge cases)

> its a simple matter to pipe the raw video to a codec in an appVM.

Performing the compression in an AppVM in order to isolate dom0 from
potential video codec bugs would be ideal, although to do so while
retaining reasonable performance (frames per second) would require a
non-trivial amount of work. You would want to eliminate excessive
copying of large amounts of data (raw frames are large), and probably
want to do something like the shared-memory composition buffer sharing
done to achieve performance in the qubes gui daemon today. I would say
this is not a simple matter as it would likely require some
non-trivial hacking to get working well.

> The threat model is pretty similar to Qubes' Trusted PDF feature.

Not quite. The PDF processing happens in a throwaway VM, whereas here
the video processing as done today happens in dom0.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-11-07 16:32, Jean-Philippe Ouellet wrote:
> On Mon, Nov 7, 2016 at 2:29 PM, Chris Laprise <tas...@openmailbox.org> wrote:
>> The framebuffer is being handled by the trusted dom0 graphics stack, so is
>> actually a trusted input.
>
> Perhaps we have run into trusted != trustworthy terminology issues.
>
> I meant to say that the content of the framebuffer being processed by
> the highly complex [1] compression algorithms is directly
> attacker-controlled, and thus attacking dom0 by displaying specially
> crafted bitmaps is a theoretical attack vector.
>
> [1]: https://sidbala.com/h-264-is-magic/ (from recent hacker news --
> serves to illustrate that video compression has significant
> complexity, and it is not impossible to imagine the existence of
> exploitable edge cases)
>

This is a good point. Perhaps the situation will be easier once dom0 has
been bifurcated into separate Admin and GUI domains.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYIZb8AAoJENtN07w5UDAwL3YQAJF+WHnRy5nM81D/YgHgfdl2
d+UZSdVTRHLHqujZCOPATys4e5ZLMtcrnTVj6HGtuNudlt46DnDMF2vgOwsz3U9A
1TZEKIX/ePE+Wlzf436mZ2wCBSdA/+kNZ32ue6zqE9ffAh4EKrTojmV5s3f/NQe4
AM2ni3fElrEyr+m7IHjyTmMKP+ycrWJ6WjszBx47fjjbL1OYljizZXYegMcFhYcW
NzzNjG0yg74+GvApTy7FGE+CrsTf8zmOzb7s9waLeGVpOKbQwEHql4uTQwIJ6y7B
zyzVMSrRjhjn3MyOcSEGeMTuvTGSuOYlMX1pRumnmR+jrbHuY9DTQBJVkBo3QhU9
ywZu16DB2BOVaWJITpiBfDXwoU+/9eqhNeegc6No2UKGvqFBlC+Xxj8XXe9l7cex
EdmCeW03Y4G3nUg/r6TF/3xvkgn/AOD2a7MxnEknmSjWydMfVWu0bPSqq+jeDUnq
7GWnM0xWbY8VUVQKwE8cjKG8VfqQyw86kfidBmPIZNiEYwMqSpRCGILabE0FhGww
3CVeHoXDsi8OovV4tqehR92q8jufnnkjTaLyeH3J4S18PpjnuA3YwVOoTXF2MECM
JywoHxTzqYNOFpO6xohXve2IQgq4gh7b9ItH9BLlAhjkG/sY4leIlRyZb90n/F0o
vVSN0vijM6AP+Ze+Dtgl
=fiqZ
-----END PGP SIGNATURE-----

[Eva Star]

It's not hard to integrate video capturing to my qubes screenshot tool
https://github.com/evadogstar/qvm-screenshot-tool/

But this need additional software like ffmpeg and silentcast to be at dom0


--
Regards

[neilh...@gmail.com]

On Tuesday, 8 November 2016 12:49:53 UTC, Eva Star wrote:
> It's not hard to integrate video capturing to my qubes screenshot tool

What is the command name for your screenshot tool...? Can it be run on the command line..?

Because I'd be willing to just write a script to run it multiple times per second, and then view the JPG / PNG images individually

I'd be willing to write that script myself right now and not even integrate it into Qubes or anything... To just do it for myself.

[Eva Star]

The tool for video is already exists. It's silentcast. Just install it
at dom0 and you will be able to make video. The only problem that it's
not at default fedora 23 repo.


--
Regards

[Chris Laprise]

On 11/07/2016 07:32 PM, Jean-Philippe Ouellet wrote:
> On Mon, Nov 7, 2016 at 2:29 PM, Chris Laprise <tas...@openmailbox.org> wrote:
>> The framebuffer is being handled by the trusted dom0 graphics stack, so is
>> actually a trusted input.
> Perhaps we have run into trusted != trustworthy terminology issues.
>
> I meant to say that the content of the framebuffer being processed by
> the highly complex [1] compression algorithms is directly
> attacker-controlled, and thus attacking dom0 by displaying specially
> crafted bitmaps is a theoretical attack vector.
>
> [1]: https://sidbala.com/h-264-is-magic/ (from recent hacker news --
> serves to illustrate that video compression has significant
> complexity, and it is not impossible to imagine the existence of
> exploitable edge cases)

I think this is one for the computer scientists. As it stands, despite
the complexity, codecs like H.264 are designed with handling chaotic,
noisy input as a top priority. Any pattern that tries to push the
encoder into a highly unusual code path is likely to simply be
identified as too expensive and become blurred more than the rest.

>> its a simple matter to pipe the raw video to a codec in an appVM.
> Performing the compression in an AppVM in order to isolate dom0 from
> potential video codec bugs would be ideal, although to do so while
> retaining reasonable performance (frames per second) would require a
> non-trivial amount of work. You would want to eliminate excessive
> copying of large amounts of data (raw frames are large), and probably
> want to do something like the shared-memory composition buffer sharing
> done to achieve performance in the qubes gui daemon today. I would say
> this is not a simple matter as it would likely require some
> non-trivial hacking to get working well.
>
>> The threat model is pretty similar to Qubes' Trusted PDF feature.
> Not quite. The PDF processing happens in a throwaway VM, whereas here
> the video processing as done today happens in dom0.

I was suggesting the compression could be done in an appVM... it should
be trivial to do so.

The result is supposed to be a sanitized, trusted document. I think this
is about as realistic for video as it is for PDFs.

Chris

[mathde...@gmail.com]

Hello,

> >
> >> The threat model is pretty similar to Qubes' Trusted PDF feature.
> > Not quite. The PDF processing happens in a throwaway VM, whereas here
> > the video processing as done today happens in dom0.
>
> I was suggesting the compression could be done in an appVM... it should
> be trivial to do so.
>
> The result is supposed to be a sanitized, trusted document. I think this
> is about as realistic for video as it is for PDFs.
>

I was able to do the following, which I believe is more in line with Qubes' philosophy and allows recording of screencasts using *any* software running in an AppVM *and* realtime streaming (desktop sharing - but view only) on teleconferencing software.

Here's the outline of the solution:

- Install and load v4l2loopback on the AppVM you want to record/simulate cam
- Capture the screen on DOM0 using ffmpeg -f x11grab -f rawvideo
- Open a qubes-rpc channel to an AppVM
- Send the stream to /dev/video0 on the AppVM, enconding to the appropriate format.

Basically, the following script on DOM0:

******
#!/usr/bin/sh

qvm-run -p \
--localcmd="/home/matheus/ffmpeg-static/ffmpeg \
-f x11grab -r 15 -s 800x600 -i :0.0+0,0 \
-pix_fmt yuv420p -threads 0 -f rawvideo -" \
untrusted \
"sleep 3 ; /home/user/Downloads/ffmpeg-static/ffmpeg \
-f rawvideo -s:v 800x600 -pix_fmt yuv420p -re -i pipe: \
-f v4l2 /dev/video0"

******

The trickiest points (for me) were to compile and install v4l2loopback as a kernel module on the template-vm (I had unmatching kernel version and headers installed - had to manually download and install the headers to compile it) and discover the combination of ffmpeg that would deliver the correct image.

Ideally, we could "extract" the x11grab code from ffmpeg and write a simpler utility that only grabs the screen and redirects all the output to the RPC channel, removing the need to bring ffmpeg into DOM0.

If that utility were built into a qubes repo I believe that would pretty much eliminate any attack vectors (as DOM0 is only being used as an input source to another AppVM which does the heavywork encoding and streaming the data).

[Chris Laprise]

This looks interesting... Thanks!

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[ar...@ethereum.org]

Do you think the same could work for screen sharing - analgous to this here: https://unix.stackexchange.com/questions/152435/sharing-your-desktop-with-google-hangouts-dual-monitor-and-gnome-shell/408532#408532

a.

[ar...@ethereum.org]

>
> The trickiest points (for me) were to compile and install v4l2loopback as a kernel module on the template-vm

yup. that's where I'm failing.

[dak...@gmail.com]

On Friday, 22 June 2018 22:18:38 UTC+10, ar...@ethereum.org wrote:
> >
> > The trickiest points (for me) were to compile and install v4l2loopback as a kernel module on the template-vm
>
>
> yup. that's where I'm failing.

https://gist.github.com/daktak/a3a1025cd9e4ce6e31b5209044877570
Got Qubes-OS 4.0 (Fedora 25) ffmpeg installed in dom0. Manually installed the rpms from archives.fedoraproject.org

[ma77...@gmail.com]

Nice work.
Can you please give the details about how to install the script?
Where to run the script:ffmpeg_record_screen.sh? in dom0 or vm-template?
Does it work for Qubes 3.2?
Thanks

[Fabian]

Hello everyone,
I know this topic is a bit older, but I want to give a small recommendation how to record the "screen" of a single VM.
I tried a lot of applications in the past to record a single window or VM output, but none of them worked at all.
A few weeks ago I found "Open Broadcaster Software", which is mainly used to live stream stuff, but it also brings a good Screen-Recording-Function, which surprisingly works well inside of a VM, both on Debian and Fedora.
It's completely Open Source and uses FFMPEG to handle the encoding.
https://obsproject.com/de/download

It's included in the default Debian Stable repository, so just "sudo apt install obs-studio" installs it.
On Fedora you need to enable the rpmfusion-free repository and then just "sudo dnf install obs-studio --enablerepo=rpmfusion-free"

Of course you could also use it in dom0 if you enable rpmfusion in dom0, the risks of that are already mentioned above.