Fom’s giant list of Qubes OS workarounds, tweaks and shenanigans

Be careful, launching firefox in your DispVM-Template is not recommended, since it’ll create a permanent profile that will be subject to profile fingerprinting.

The recommended approach is to create a policies.json file in your TemplateVM that will be used to customize new firefox profiles.

I explained everything in great detail here, including adding/removing search engines: [Guide] Automatically install extensions and configure new (dispvm) hardened Firefox profiles with arkenfox user.js and policies

How to change Qubes OS to Dark mode

Credits goes to

Anon81475885, Sven & Szewcu - Guide: Xfce global dark mode in Qubes 4.0 / 4.1
Previous Highlight7 - https://www.reddit.com/r/swaywm/comments/v032iv/how_to_enable_dark_for_gtk4_apps/

Instructions

Dom0

  1. For Dom0, Anon81475885’s guide still works, so follow it here: Guide: Xfce global dark mode in Qubes 4.0 / 4.1

  2. If your Dom0 taskbar/panel seems inexplicably immune to the changes impacting the rest of your Dom0 UI its probably because you didn’t have “save session for future logins” ticked as you logout/restart/shutdown. (So if you’ve previously disabled this via “session and startup” that’s why it isn’t working.) You only need to tick “save session for future logins” once after your change, you can untick it afterwards if you don’t like letting your session save.

Fedora 36 minimal

Changes in Fedora 36 seemingly broke most of the tricks in Anon81475885’s guide so we have to go rogue at this point.

  1. Open a terminal in your AppVM and type:
    gsettings set org.gnome.desktop.interface color-scheme "prefer-dark"
    (That’ll sort out libreoffice, nautilus/files and standard gnome apps like calculator.)

  2. Then create ~/.config/gtk-3.0/settings.ini and make sure it includes:

[Settings]
gtk-application-prefer-dark-theme=1

(That’ll sort out GTK3 apps like xed )

  1. Open a root terminal in your TemplateVM and type:
    sudo dnf install adwaita-qt5

  2. Then edit your template’s /etc/environment file to include:
    QT_STYLE_OVERRIDE=adwaita-dark

(That’ll sort out QT5 apps like qpdfview, but they’ll frequently be missing icons – sorry I don’t have a solution for this yet.)

Eeek, good catch! I’ve put a big warning on my post for now, i’ll revisit it or delete it in the future. I’ve been tidying up weeks of notes most the day and I need a break from my own scribblings.

I’m going to appeal for help with something completely unrelated elseware on the forum and call it a day. Thanks for the feedback, please keep it coming if you spot any more issues!

Thanks for sharing notes with us.The others might consider customizing default Firefox this way, not messing with opening it in any template.

Setting non-existing search engine as the default in Firefox can be found in the last post is in the topic from my quote and it’s basically the same you pointed to.

Your suggestion suffers from the same flaw: it creates a permanent profile, thus it’s not recommended since there’s a better way: Fom’s giant list of Qubes OS workarounds, tweaks and shenanigans - #21 by BEBF738VD

Offtopic

There’s no any flaw. You are mixing two terms: customizing and fingerprinting. I have never spoken about the latter one.
I simply want my Firefox to looks and acts the same way I start it as a regular user who cares about security (by being secure while online, as well as not starting it in any template among other things), not the one who’d want something to hide.
Fingerprinting is completely different topic there, and for it I’d never use Firefox, because fingerprinting is about anonymity and as we all know Qubes is about security. For anonymity, there’s Whonix there, for example…

But let’s not spam the topic, or maybe it’s a good idea people to read this here and to reconsider their deployment scenarios…

2 Likes

You could try setting QT_QPA_PLATFORMTHEME=qt5ct. Alternately try to start the app with --platformtheme qt5ct.

You can customize and de-fingerprint simultaneously. I just got a totally disposable browser to come up configured the way I want it, the first time, with no old profile being used; it is, in other words, becoming what I want the first time it’s run. And it has the arkenfox fingerprint stuff and other “hardenings” from his setup.

In short outline:

  1. Create a template with a fresh firefox install on it.
  2. Create a dvm template based on that.
  3. Start up firefox in the dvm template.
  4. Set up firefox the way you like it–do nothing else.
  5. Grab the .mozilla/firefox/aaaaa-/prefs.js file from that machine and copy it somewhere else. The aaaa will be the profile name that firefox set up for you. There will likely be two of them, one will be empty, the other will have -esr in the name.
  6. This file will be full of a lot of cruft, but you can experiment with removing things from it and then dropping it into the same directory on the dvm template (not the disposable) but name it user.js when you do so. Running firefox in disposables should let you see what the effect is.
  7. Later on you can treat this file just as if it were the arkenfox file (or you can even just append your stuff to a copy of that file), turning it into a firefox.cfg file and installing it on the temple (yes the template) as described in here: [Guide] Automatically install extensions and configure new (dispvm) Firefox profiles with arkenfox user.js and policies

NB: You cannot set the default browser in this way. The best I was able to do was set up the separate search bar, deactivate searching in the main URL bar, force it to only show my favorite search engine as a suggestion. But in the separate search bar, it still defaults to google. You will have to follow the instructions about policies in the link, and further down in the thread is the actual policy that will finally drive a stake through google.

Offtopic

Thanks. Probably it would help someone. Where it doesn’t suit me is

I never start anything in any qube that is in any way a template, except terminal and file manager.

Above, I explained how to do that by starting it in a dispVM. Get the profile there and do what you like to with it later.

Customizing might contain de-fingerprinting as well. But as I said, I don’t use Firefox in order not to be fingerprinted. I use Firefox when I actually want to be fingerprinted: online banking, logging to trusted sites and services, etc. To do this securely, I set Firefox dispVM with 800MB RAM and run dispVM (Firefox) per site. Separate dispVM (Firefox) is started for searches only (and when search on Google, exclusive dispVM for that). I don’t see a point to harden Firefox in order to log in to bank portal and to a gmail in the same instance of Firefox. I cannot be assured that can be achieved so I assume it is not feasible, thus run separate dipsVMs.

Huh, there’s an edit timer isn’t there? So I can no-longer go back and correct/improve my guides based on feedback? :thinking:

Well, looks like I didn’t think this through :expressionless:.

Regarding your third point here. I could be mistaken but I think anyone who (like me) has been forced to do the steps outlined in my “How to install Qubes OS when your motherboard hates it” instructions will have a system which bypasses/ignores grub.cfg and skips straight to xen.cfg. (Mostly because that seems to be what the official fix recommends, though I think restoring grub is possible.)
So, (I haven’t tried it,) but I suspect your solution might not work on my system, at least not without me restoring grub first.

Your point regarding sudoedit seems very good to me though and if I could edit my posts i’d be inclined to put that in.

Thanks, sounds promising, I’ll try this out when I get time.

…I should have said, I consider that initial DVM template to be a throwaway–you delete it after you get what you wanted out of it. Which makes that template a de facto disposable. With a dvm template you have the luxury of running it multiple times and tweaking what you did before. But then if you’re going to do that you might as well treat it like an AppVM…which is what it is, in fact, anyway. (That’s why I’m not quite as fussy as you are when it comes to DVM templates–I’m willing to “run” them once or twice for the purposes of making a configuration right though it’s not preferred. Make it a TemplateVM on the other hand, and I go Full Frontal Qubes on people…)

Be that as it may, you could certainly do that step in a DVM itself, but of course you have to grab the files you want before shutting it down!

Agreed. I wasn’t clear enough too. When I said offline I meant that updates-proxy-setup service is specifically disabled, beside netVM set to none.

Thanks for this great resource

Because I recently spent a lot of time on an obscure issue, I would like to add it here if appropriate

If you have USB controllers that are put into a bad state at boot via FLR, it is likely caused by sysfs operations in the initramfs script which supports usb-sys configurations

There’s a Qubes-specific workaround inspired by this proxmox post

The issue manifests as:

  • FLR waiting and timeout of USB controllers at boot
  • If the system eventually boots, you will see invalid and missing data for the device in lspci -v
  • You may receive more FLR timeouts and a fail to boot sys-usb after a couple of minutes, - You may receive an “invalid PCI header” message from libvirt when starting sys-usb.

In both cases of the sys-usb start cases, the error is fatal and sys-usb won’t actually boot

My Qubes forum post on this is here

For convenience, the workaround is to modify /usr/share/dracut/modules.d/90qubes-pciback/qubes-pciback.sh (unmodified source is [here])(qubes-core-admin-linux/dracut/modules.d/90qubes-pciback/qubes-pciback.sh at 3f0afb7030276f7afc0212bbaec187abdab72860 · QubesOS/qubes-core-admin-linux · GitHub)

Add the following at the top of the file, one per problematic BDF (any line before the sysfs operations occur)

BDF1=f4:00.0
BDF2=8d:00.0
# Fool the kernel into thinking there are
# no reset mechanisms available for
# the specified BDFs, to prevent implicit
# FLR requests from being sent during
# bind/unbind to/from a driver via sysfs
echo "" > /sys/bus/pci/devices/0000:$BDF1/reset_method
echo "" > /sys/bus/pci/devices/0000:$BDF2/reset_method

That allows the controllers that “break” when issued FLR to successfully be assigned to pciback without going into a bad state.

They can then be attached to a sys-usb (you may at that point need the well-documented no_strict_reset=True)

This issue (the precise trigger, and the solution) is unique to USB controllers and separate from FLR issues with GPUs and other devices, because there is special logic to handle USB controllers when you have sys-usb and a USB keyboard

I’ve asked in the linked post for a better way to resolve the issue, but the above method works