Set Dom0 wallpaper service

[marmarek]

Community Dev: @evadogstar Partial PoC: https://github.com/evadogstar/qvm-wallpaper-tool/

---

Reported by joanna on 11 Apr 2011 10:14 UTC Currently there is no easy way for the user to set a custom background (wallpaper) for Dom0 desktop. Of course, one can try to copy JPEG to Dom0 using tricks with qvm-run, but that is an unsafe operation (and this is precisely why there is no tool for file copy to Dom0).

Better idea is to let the user set the wallpaper in one of the AppVMs (they have the same screen resolution), using the already existing mechanisms (e.g. right click on some JPEG and choose 'Set as wallpaper'). Then, the gui-agent should inform the guid that the current AppVM's wallpaper should also be displayed in Dom0 as root window.

This way we allow for custom wallpapers in Dom0 without introducing any security problems.

Migrated-From: https://wiki.qubes-os.org/ticket/215

[marmarek]

Modified by joanna on 28 May 2011 09:10 UTC

[marmarek]

Modified by joanna on 3 Sep 2011 12:04 UTC

[marmarek]

Modified by joanna on 8 Oct 2012 09:23 UTC

[marmarek]

Comment by Zrubi on 19 Feb 2013 14:56 UTC And what if :

• the AppVM is not running?
• one set a walpapper from multiple AppVMs?

Anyway I do not see real problem here: any qubes users only should put trusted files in dom0 - including the walpappers.

[marmarek]

Comment by joanna on 20 Feb 2013 10:51 UTC @Zrubi: and where do those "trusted" wallpapers come from? From your camera? Is it trusted? Say it is (let's not be paranoid, shall we). But how did you get it from your camera? You probably downloaded it first to your "personal" VM, edited a bit, and then created my_super_wallpaper.png, right? Now, copying this file to Dom0 essentially makes Dom0 as trusted as your personal VM -- not a very good deal IMO.

[marmarek]

Comment by joanna on 20 Feb 2013 10:52 UTC Anyway, we already have a good solution for this -- will be announced soon...

[marmarek]

Comment by joanna on 24 Feb 2013 15:28 UTC We can use a similar approach:

http://theinvisiblethings.blogspot.com/2013/02/converting-untrusted-pdfs-into-trusted.html

[marmarek]

Modified by joanna on 1 Aug 2013 12:52 UTC

[marmarek]

Modified by joanna on 5 Dec 2013 18:59 UTC

[marmarek]

Modified by joanna on 24 Mar 2014 11:57 UTC

[marmarek]

Modified by joanna on 17 Apr 2014 16:08 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:13 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:13 UTC

[rootkovska]

As discussed previously, this service should be much simpler, and based on qvm-convert-img too:

1. qubes.Filecopy untrusted image to a DispVM
2. Run qvm-convert-img there
3. Pipe the converted file to Dom0.

Perhaps we could even skip DispVM?

[marmarek]

https://github.com/evadogstar/qvm-wallpaper-tool/blob/master/qvm-wallpaper-tool#L79 convert $TMP_DOM0_WALLPAPER -strip $DOM0_STORE_SECURE_WALLPAPER This will let convert guess the format and run whatever parser it gets. It can end really bad. Like this: https://imagetragick.com/

Proper way would be to select a simple format (IMO even png/jpg is too complex), then force it using a prefix for input. Take a look at https://github.com/QubesOS/qubes-app-linux-pdf-converter. Especially here: https://github.com/QubesOS/qubes-app-linux-pdf-converter/blob/master/qpdf-convert-client#L102 We have also python module which handle this already: https://github.com/QubesOS/qubes-linux-utils/blob/master/core/imgconverter.py#L122 So the service should be simple:

• VM outputs image dimensions (echo $width $height), then bitmap array (convert some-input rgb:-)
• dom0 receives dimensions (read $width $height), validate it (check if really numbers, max size etc), then receive bitmap: convert -size ${width}x${height} -depth 8 rgb:- some-output

Initially the idea was to expose it as a qrexec service, so a VM may call it - and if the user accept policy prompt, it will set the wallpaper.

[marmarek]

@marmarek Yes, I noticed about issue with IM, but I thought that it is already fixed.

It doesn't matter whether this particular issue is fixed. We don't want to expose any complex code to untrusted data, because complex code have bugs - some of them are know, some are not (yet).

What do you think about new version at my repository?

Much better :) I've added some minor comments.

• receive Width and Height of image with IM. Better to user some function for that

You can save one qvm-run call by getting both dimensions at once (like, space separated). Or generally reusing the format of pdf-converter (dimensions on the first line, then binary bitmap) - that would work with just one qvm-run call.

• all conversions done at AppVM (vs. DispVM)

It's ok.

• maybe better to transfer output from convert to pipe and read pipe without file operations.

Yes, it would be better, at least to not leave some junk on the disk. But not that important. Much more important is to clean that temporary files...

Maybe better to open window at AppVM that give user ability to select image? Action initiated from dom0. It was the original idea. If tool started without args. It ask user to select AppVM then file on it.

Yes, I'd vote for this option. You can use zenity --file-selection for that.

Also it would be better to call a service in the VM, instead of calling tools (convert etc) directly. It's simple: instead of qvm-run VMNAME foo, put that command(s) in /etc/qubes-rpc/some-service-name in the VM and call qvm-run VMNAME 'QUBESRPC some-service-name dom0 ("dom0" is the name of calling VM). Then the script in /etc/qubes-rpc/some-service-name can have some of the logic, like call zenify --file-selection first, then output all the data (dimensions, bitmap) at once. It would slightly simplify dom0 part, which is a good thing. As before - take a look at pdf converter for examples.

[marmarek]

What benefit is to use RCP calls at separated files instead of qvm-run (with all the code at one place)?

Flexibility:

• allows to add later other OS support (simply implement those services there)
• do not hardcode tools names/paths - you can easily use whatever is available in given template (for example NixOS doesn't have standard /usr/bin paths)

Ohh, and I'm uploaded new version. Now it's with GUI mode & console mode by default. qvm-screenshot-tool --gui to start it at GUI mode.

Thanks! Will look at it later.

Who will add all of them to newly created template by user? How to name them? "qubes.ConvertImageToRgb" ?

Hmm, there is already qubes.GetImageRGBA :) Totally forgot about this... Usage:

echo $path | qvm-run --pass-io $VMNAME 'QUBESRPC qubes.GetImageRGBA dom0' > $tempfile_with_header
WH=$(head -1 $tempfile_with_header)
# get content
tail -n +2 $tempfile_with_header | convert ....

[marmarek]

Good, but it's more subject to vulnerabilities that my version, because it accept any file to identify/convert input without limitations and do not check that header == extension.

In the output you get always RGBA only, regardless of input format (and your dom0 part should threat it this way, even if it sends you full JPEG file - in such a case result will be quite funny ). It doesn't matter what format you support in the AppVM here, as you've probably parsed that file a dozen of times already (for example in file selection dialog you probably have some thumbnails).

Also it have hard coded 8 bit depth of output image. :( It's 256 colors only. :(

It's 8 bits per color, so 16777216 colors.

[xahare]

Why not screenshot? run imageviewer in fullscreen, hit prtsc, which can save the image in dom0, set as wallpaper. no file copies, or any of that scary stuff. the only thing to be scared of is the screenshot tool included in kde / xfce

[andrewdavidwong]

Why not screenshot?

https://github.com/QubesOS/qubes-issues/issues/1324#issuecomment-222620555

[mannp]

Wondered if this was being utilised for Qubes v4 at all, as I would like to update my dom0 wallpaper (safely).

Thanks

[fosslinux]

@evadogstar Is this done yet? Does this work in Qubes 4.0?

[andrewdavidwong]

@evadogstar, are you still working on this? (I'm updating the Community-Developed Feature Tracker.)

[tk-47]

I must be missing something here. I agree that it would be nice to be able to set different backgrounds, but the thought of copying an image to Dom0 seems crazy. That flies in the face of the entire point of Qubes. Personally, I would rather the developers upload more stock images to resolve this than allow an appvm to talk to Dom0. Doing so just creates a completely unnecessary vulnerability that could .. read as would .. be exploited. So, one vote for more stock images added to the distro so that you can keep your background fresh and one BIG vote not to allow communication or file transfer from appvms to Dom0.

[andrewdavidwong]

I must be missing something here. I agree that it would be nice to be able to set different backgrounds, but the thought of copying an image to Dom0 seems crazy. That flies in the face of the entire point of Qubes. Personally, I would rather the developers upload more stock images to resolve this than allow an appvm to talk to Dom0. Doing so just creates a completely unnecessary vulnerability that could .. read as would .. be exploited. So, one vote for more stock images added to the distro so that you can keep your background fresh and one BIG vote not to allow communication or file transfer from appvms to Dom0.

Stock images are not necessary. You can set any arbitrary image as the wallpaper in dom0 without ever importing any extra files into dom0. Simply view the image in full screen mode in any VM, then take a screenshot from dom0. You now have a perfect resolution wallpaper image natively created in dom0.

Then why is this issue open? See: https://github.com/QubesOS/qubes-issues/issues/1324#issuecomment-222620555

[moonlitOrca]

I was reminded of this topic after seeing the presentation by nitrokey of common user problems and friction points at the qubesOS conference yesterday. Clearly the tool that @evadogstar was working on is no longer in development (almost 7 years ago), from reading this issue thread.

I saw in the related issue that @andrewdavidwong just mentioned in the last post that the command qvm-get-image can perform generally the needed operation to get an image into dom0 (safely?). Would it be a reasonable course of action to simply create a python script that could be integrated as a tool or setting that would call this function to operate on a user indicated file, and then set it as the wallpaper? I've never coded in python before, but I know the language is not complex to generally use, and I bet, with a bit of time, I could figure out how to build that if I knew which CLI calls to make and where to copy things to to set the wallpaper.

Would that be a feasible solution? I know a screenshot method can be used, but I really feel that setting wallpaper is so fundamental to general PC use for almost all users I've met that it would be beneficial to have a direct approach to doing this safely.

[andrewdavidwong]

I saw in the related issue that @andrewdavidwong just mentioned in the last post that the command qvm-get-image can perform generally the needed operation to get an image into dom0 (safely?).

Link? I don't remember saying that.

[moonlitOrca]

Then why is this issue open? See: #1324 (comment)

This is an instance where the English meter wasn't conveyed clearly in the text. I mean to say that you mentioned and linked an issue above ^ in which someone else says that the command qvm-get-image can be used for this.

So I am curious if this can be done and if so, if it can be built into a python tool to finally solve this issue in a more direct way? Again, I'm willing to try if it is an appropriate solution, from a security standpoint, and if I can get information on how the command should be used,.

[DemiMarie]

@moonlitOrca Setting the dom0 wallpaper is not inherently a dangerous operation, so all that is needed is a qvm-get-image wrapper.