Use different Wallpaper for Whonix-Gateway to distinguish from Whonix-Workstation

Development
1

For the wallpaper on KDE5 I found some links of which the last is more useful I think:

https://forum.kde.org/viewtopic.php?f=289&t=131783

https://techbase.kde.org/Development/Tutorials/Plasma5/QML2/GettingStarted#The_.desktop_file

https://techbase.kde.org/Development/Tutorials/Plasma5/ThemeDetails#Wallpaper_Access

1 Like
2

I was also looking into changing the wallpaper depending on live or non-live mode.
To change it via the command line you can use the code posted here:

qdbus org.kde.plasmashell /PlasmaShell org.kde.PlasmaShell.evaluateScript 'var allDesktops = desktops();print (allDesktops);for (i=0;i<allDesktops.length;i++) {d = allDesktops[i];d.wallpaperPlugin = "org.kde.image";d.currentConfigGroup = Array("Wallpaper", "org.kde.image", "General");d.writeConfig("Image", "file:///media/sda2/Background/SpaceWall/Escape_Function.jpg")}'
1 Like
3

Great!

Related:

https://github.com/Whonix/Whonix/issues/318

Are there any wallpapers installed by default already?

Let’s not install kde-wallpapers package by default to avoid another 90 MB extra image size?

Non-trivial development effort:

  • add to https://github.com/Whonix/whonix-gw-kde-desktop-conf
    • create debian/whonix-gw-kde-desktop-conf.postinst to run that qdbus command
    • somehow do this only for new builds, i.e. don’t change the wallpaper for users who upgrade (otherwise we’ll see tons of concerned users who think they found evidence of a hack)
    • do this only once, i.e. when the package is later upgraded, don’t do it again (to not change the wallpaper back if the user changed it to something else in meanwhile)
    • depend on qtchooser (provides qdbus)

Help welcome!

1 Like
4

Why not come up with a custom Whonix specific background similar to this:

Whonix_Portal.jpg1704Ă—460 66.8 KB

or this:
hero-background.jpg1500Ă—622 18 KB

with the Whonix logo and then maybe in the bottom right corner something like “Whonix Workstation persistent” and respectivley for live mode and the gateway.
Checking if we run live or on the gateway or workstation is not the problem. I’ll take a closer look at the other points.
If we can check if the current wallpaper uses another image than the one we officially would use we could prevent changing it back in case the user has set a custom one. Maybe a similar check could be made e.g. check if we run on 13 and just don’t install the package. However, this would also mean you can’t easily distinguish between live and persistent mode. During some (or all?) of my tests upgrading 13 to 14 the background changed anyways. As far as I can remember also during some normal non-whonix upgrades between debian versions. So it is something which could be expected.

2 Likes
5

Looks nice, however… Not sure vs https://github.com/Whonix/Whonix/issues/318? @HulaHoop

Another thing, should we make shoulder surfing detecting one is running Whonix trivial?

Running on gateway: there is a /usr/share/anon-gw-base-files/gateway as identifier file for that indeed.

ischroot might help to figure out we’re currently in a build process. tb-updater is using that.

(Also a good template for a postinst script.)

6

Not easy to have such exceptions and consistent packages as well as carrying this around for further versions. The package always being installed on Non-Qubes-Whonix makes most sense. Non-issue however, as per below.

  • Alright so for major upgrades changing the desktop wallpaper is acceptable. However, we should make sure that package upgrades later on won’t change any custom wallpaper away. The ischroot method should provide for this perfectly. That would fit perfect into whonix-gw-kde-desktop-conf.

  • For Whonix 13 → 14 upgrades we can use GitHub - Kicksecure/legacy-dist: Prepare older Build Versions of Whonix for Upgrade postinst (already existing postinst) to change the gateway wallpaper. (whonix-legacy already has a done-once mechanism always.) Could just copy the wallpaper change command inside thirteen_dot_x_to_fourteen_dot_x function in whonix-legacy postinst.

This is yet another bullet point.

  • grub-live package (since optional in Whonix 14) can have independently its mechanism to change desktop background. The above mechanisms would still be sane to have. Would somehow conflict with users changing their desktop wallpaper and setting to turn this on/off does not seem ideal either. Not sure how users could best be notified about running in what mode… Perhaps ask in grub-live thread or new forum thread?
7

Regarding the threat, how relevant would that be if we use our own wallpaper? The user has to trust the Whonix, Debian, Linux Kernel … devs anyways.

Tails once had the option to make it look somewhat like Windows though it was abandoned because (afaik) no one wanted to maintain it and I’d argue if this would have been a pressing issue this would not have happened.
Tails, Whonix and the average linux distro don’t look like Windows anyways. If you think using Whonix would raise some eyebrows you could say the same about the torbrowser. Not sure if Tails changed the look of the browser back then.

1 Like
8

10mb only:

https://packages.debian.org/stretch/kde-wallpapers-default

You’re overthinking this IMHO. There was a time when you changed wallpapers for every Whonix release IIRC.

1 Like
9

That’s a valid point. Now its a question of maintaining an extra package which we can avoid by just using one from the default selection which is quite aesthetically tolerable.

For example with some KDE problem, the KVM VM does not occupy the fullscreen. It will be a while before fixes come to Debian stable. A custom wallpaper will probably need to be tested to make sure it works for both resolutions (the normal one and the reduced one). Doable but up to you.

As for the shoulder surfing threat - we already have a Whonix logo in Tor Browser. So it already applies I think.

1 Like
10

HulaHoop:

10mb only:

Debian -- Error

Did you check dependencies?

Actual output of sudo apt-get install kde-wallpapers-default? Due to
dependencies, it’s 90 MB?

11

Changing the wallpaper for live mode would imho make only sense when if we use custom images since otherwise we would still maybe run into the issues mentioned by HulaHoop but only for the grub-live package.
If we use upstream images I’d go at first for some icon on the taskbar which would always be present and if this is not easily scriptable for something with notify-send which the user needs to click away.

2 Likes
12

Sounds good!

notify-send however is easily overlooked. (Would still be acceptable though.) Tray icon sounds so much better.

Perhaps this could even be integrated into sdwdate-gui (but then renamed of course). Wondering anyhow if Tor status (and things such as live mode) should get a separate systray icon (probably not liked by Qubes) or if sdwdate-gui could be removed and serve as Whonix systray.

On the other hand too many things in one application can also be weird. grub-live is a Whonix-independent package.

13

I see. I don’t know if its scriptable in the build process. Will forcing it to install without dependencies work?

sudo dpkg --force-all -i kde-wallpapers-default

14

Doesn’t have dependencies. (See apt-cache show kde-wallpapers-default.) So dependencies and size is not an issue.

But also has not much files.

apt-file list kde-wallpapers-default

kde-wallpapers-default: /usr/share/doc/kde-wallpapers-default/changelog.Debian.gz
kde-wallpapers-default: /usr/share/doc/kde-wallpapers-default/copyright
kde-wallpapers-default: /usr/share/wallpapers/Elarun/contents/images/2560x1600.png
kde-wallpapers-default: /usr/share/wallpapers/Elarun/contents/screenshot.png
kde-wallpapers-default: /usr/share/wallpapers/Elarun/metadata.desktop

Effectively only /usr/share/wallpapers/Elarun/contents/images/2560x1600.png. Would that help?

My mistake, only sudo apt-get install kde-wallpapers would require 90 MB.

1 Like
15

Sure that’ll work :slight_smile:

1 Like
16

https://github.com/Whonix/whonix-gw-kde-desktop-conf/commit/7171f8ec203922fca53ccb45368f234ee42b4b7a

Please review. Untested.

Do you think it will be an issue running qdbusas root (this is what the postinst would be doing)?

17

It might not work since the postinst runs at build time (or at package installation time). qdbus might require a running qdbus service, which there is not at Whonix image build time.

Running this in Qubes reveals this command is possible to fail under certain conditions. That would be bad since the broken postinst script would break the package management apt.

qdbus org.kde.plasmashell /PlasmaShell org.kde.PlasmaShell.evaluateScript 'var allDesktops = desktops();print (allDesktops);for (i=0;i<allDesktops.length;i++) {d = allDesktops[i];d.wallpaperPlugin = "org.kde.image";d.currentConfigGroup = Array("Wallpaper", "org.kde.image", "General");d.writeConfig("Image", "file:///usr/share/wallpapers/Elarun/contents/images/2560x1600.png")}'

Cannot find 'org.kde.PlasmaShell.evaluateScript' in object /PlasmaShell at org.kde.plasmashell

18

Is it really necessary to use this during the build process? You could also just put a script in the KDE autostart folder which checks if it is running on the workstation, gateway, live …
This draft does what it should do. Path to the images should probably be changed.

Edit: I also have a version of this lying around which checks if a custom wallpaper is set and then does nothing. Will post tomorrow.

19

Algernon:

Is it really necessary to use this during the build process?

  • It’s not strictly required to do this in the build process.
  • A settings file drop-in would be the most preferable clean solution.
    Easier to audit a settings file than the result of a command being run.
  • A postinst based solution is also good since it works for new and
    updates builds.
  • An autostart based solution is a bit less great than above since it
    has higher competitively (autostart entry that calls a script) but also
    good enough.

You could also just put a script in the KDE autostart folder

What folder is that?

https://wiki.archlinux.org/index.php/KDE#Autostarting_applications

  • /etc/xdg/autostart?
  • ~/.config/autostart through /etc/skel?

We should very much avoid writing into the home folder directly. Causing
many issues. Wondering if there is a summary why easily accessible
anywhere already.

20

Version 2 of the script is here .
BUT it does not work in a reliable way! KDE is buggy. Not sure if it is the one mentioned here: https://docs.kde.org/trunk5/en/kde-workspace/kcontrol/autostart/ and there is some kind of race condition. It only works when the VM has a high amount of RAM and multiple CPUs assigned. Otherwise it fails consistently for me. Executing the script always works when the desktop has finished loading but of course it makes no sense to do this manually.

True. Alternative would be some extrapackage which gets installed during the updates. Or add it to an existing one like usability-misc?

I used:
~/.config/autostart-scripts

It does not exist on a new VM not sure if it is created by KDE or Whonix on the first boot.

Like?