Set Dom0 wallpaper service

[marmarek]

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 28 May 2011 09:10 UTC

[marmarek]

Modified by joanna on 3 Sep 2011 12:04 UTC

[marmarek]

Modified by joanna on 3 Sep 2011 12:04 UTC

[marmarek]

Modified by joanna on 8 Oct 2012 09:23 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 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: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 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]

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 1 Aug 2013 12:52 UTC

[marmarek]

Modified by joanna on 5 Dec 2013 18:59 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 24 Mar 2014 11:57 UTC

[marmarek]

Modified by joanna on 17 Apr 2014 16:08 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

[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?

[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?

[evadogstar]

#1324 (comment)

It's do some part of that.
2 time conversion
1 time at AppVM where images is located, not at DispVM, but seems it's possible to do, but does not know how to create temporary DispVM

[evadogstar]

#1324 (comment)

It's do some part of that.
2 time conversion
1 time at AppVM where images is located, not at DispVM, but seems it's possible to do, but does not know how to create temporary 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]

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.

[evadogstar]

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

What do you think about new version at my repository?

1. Work only with jpg and png, and ImageMagick convert utility "thread" it as provided $extension from filename or die if it's wrong header.
2. At AppVM script receive image size, send it to dom0 to validate it.
3. Convert original image to rgb at AppVM
4. Move rgb to dom0
5. Reconvert to original format at dom0 from rgb (load it exactly as RGB or die)

Issues:

• receive Width and Height of image with IM. Better to user some function for that
• all conversions done at AppVM (vs. DispVM)
• maybe better to transfer output from convert to pipe and read pipe without file operations.

Notes:
Sorry, I do not know nothing about qrexec service. And I do not fully support the idea that AppVM can initiate the action. It's already exists "notify-send" and others. that can be user to flood user GUI. Complex flooding with other applications request can hide interface from user if somebody will call all of them at a time.

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.

[evadogstar]

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

What do you think about new version at my repository?

1. Work only with jpg and png, and ImageMagick convert utility "thread" it as provided $extension from filename or die if it's wrong header.
2. At AppVM script receive image size, send it to dom0 to validate it.
3. Convert original image to rgb at AppVM
4. Move rgb to dom0
5. Reconvert to original format at dom0 from rgb (load it exactly as RGB or die)

Issues:

• receive Width and Height of image with IM. Better to user some function for that
• all conversions done at AppVM (vs. DispVM)
• maybe better to transfer output from convert to pipe and read pipe without file operations.

Notes:
Sorry, I do not know nothing about qrexec service. And I do not fully support the idea that AppVM can initiate the action. It's already exists "notify-send" and others. that can be user to flood user GUI. Complex flooding with other applications request can hide interface from user if somebody will call all of them at a time.

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.

[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]

@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.

[evadogstar]

You can save one qvm-run call by getting both dimensions at once (like, space separated).
done

Much more important is to clean that temporary files...
It do that from initial version :)

Also it would be better to call a service in the VM, instead of calling tools
New version use already exist qubes.FileSelect RPC Call. Other actions done with qvm-run as it was before. I'm note sure. Is it a good idea to create 2-3 separated files at AppVM with each 1-2 lines of code? Who will add all of them to newly created template by user? How to name them?
"qubes.ConvertImageToRgb" ?

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

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.

[evadogstar]

You can save one qvm-run call by getting both dimensions at once (like, space separated).
done

Much more important is to clean that temporary files...
It do that from initial version :)

Also it would be better to call a service in the VM, instead of calling tools
New version use already exist qubes.FileSelect RPC Call. Other actions done with qvm-run as it was before. I'm note sure. Is it a good idea to create 2-3 separated files at AppVM with each 1-2 lines of code? Who will add all of them to newly created template by user? How to name them?
"qubes.ConvertImageToRgb" ?

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

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.

[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]

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

[evadogstar]

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

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

Also it have hard coded 8 bit depth for output image. :( It's 256 colors per pixel only. :(
Seems, it's too large losses in picture quality for wallpaper image... :(

[evadogstar]

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

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

Also it have hard coded 8 bit depth for output image. :( It's 256 colors per pixel only. :(
Seems, it's too large losses in picture quality for wallpaper image... :(

[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.

[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

[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?

#1324 (comment)

[andrewdavidwong]

Why not screenshot?

#1324 (comment)

[evadogstar]

The tool almost done. It works. Seems need only to change it to use Qubes_RPC (as Marmarek suggest)

[evadogstar]

The tool almost done. It works. Seems need only to change it to use Qubes_RPC (as Marmarek suggest)

[mannp]

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

Thanks

[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?

[fosslinux]

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