Enabling Bluetooth on Qubes R4.1

Hi guys,

I’m really new to Qubes and have been looking for a while with painly efforts to enable my built-in bluetooth USB device (Intel Corp. Bluetooth 9460/9560 JfP) on my laptop (ROG Zephyrus GX501GI). My templates are based on Debian11 and the built-in USB keyboard device of my laptop is on the same bus as my bluetooth device.

First of all, I’m fully aware of the risk implications that this would cause and I am fine with it. The only mouse I’ve available is my bluetooth mouse and I really hate my touchpad at the moment.

Could someone provide me with a step-on-step guide on how to do it? The blueman manager in dom0 which I’ve updated and enabled previously doesn’t connect with BlueZ, even after enabling bluetooth on the terminal.

My guess was to do it through my sys-usb, but I don’t know how to do this.

Please help

In the template of your sys-net just install blueman:

sudo dnf install -y blueman

Restart sys-net and there should be a tray icon with all the options available.

Now my question is: how did you enable dark theme for the panel? It applies only partially for me.

1 Like

@gokarob473: below should be solve your ‘light parts’…

Source & Info: Make Qubes OS dom0 GUI adhere to selected XFCE/Gtk theme · Issue #7389 · QubesOS/qubes-issues · GitHub

Install the package qt5-qtstyleplugins with:

sudo qubes-dom0-update qt5-qtstyleplugins

then insert in /etc/environment:

-------------[Start]---------------------
QT_QPA_PLATFORMTHEME=gtk2
-------------[End]-----------------------

in dom0 terminal do:

export QT_QPA_PLATFORMTHEME=gtk2

---

finally you can check, if all changes were set & working:

[TheGardner@dom0]$ cat /etc/environment
QT_QPA_PLATFORMTHEME=gtk2

[TheGardner@dom0]$ echo $QT_QPA_PLATFORMTHEME
gtk2

[TheGardner@dom0]$ sudo dnf info qt5-qtstyleplugins
Qubes OS Repository for Dom0                                                     1.9 MB/s | 3.0 kB     00:00
Installed Packages
Name         : qt5-qtstyleplugins
Version      : 5.0.0
Release      : 39.fc32
Architecture : x86_64
Size         : 1.2 M
Source       : qt5-qtstyleplugins-5.0.0-39.fc32.src.rpm
Repository   : @System
 From repo    : qubes-dom0-cached
Summary      : Classic Qt widget styles
URL          : https://github.com/qtproject/qtstyleplugins
License      : LGPLv2 or GPLv2
Description  : Classic Qt widget styles, including cleanlooks, motif, plastique, qgtk.
1 Like

I keep getting this, considering the fact that the template of my sys-net is based on debian-11. Looks like it’s even not capable to find my bluetooth device…

As for your question: I’ve installed the Whiskers menu (Replacing the "Q" menu with the better "whisker menu") and then I chose the Adwaita-dark style in the application called Appearance.

In the Debian template just install blueman:

sudo apt install blueman -y

And analogically just restart sys-net and there should be a tray icon with all the options available.

1 Like


Nothing changed unfortunately…

What happens if you run the Bluetooth Manager launcher seen on your photo or the tray applet via commandline: blueman-applet?

Did you ever get this to work? I found the same thing when I installed blueman to attempt to use a bluetooth mouse. I have no desire for bluetooth really except for the mouse, but even using the included USB dongle will not work properly. (oddly it partially works…meaning that I can connect it to a single VM and then I have an invisible mouse cursor that can click and do things, aside from the dom0 provided one). I suppose that is likely a matter of dom0 not recognizing the new pointing devices as THE mouse, but instead as something other. If anyone knows how to deal with that, then that would also be tantamount to fixing my problem, and maybe more secure than normal bluetooth since the dongle would only be used when I am actively mousing? not sure on the implications of that.

Regardless, I know bluez is installed in my fedora template, but it seems that the bluetooth.service stays dead and will not start when I tell it to systemctl enable bluetooth.service
followed by systemctl start bluetooth.service… this seems to be the same issue you were having, if I read correctly.

Are you sure, it is a Bluetooth mouse? - or is it a wireless mouse?

The basic difference between a wireless (RF) mouse vs. a Bluetooth mouse is that RF mice need a USB dongle to connect, while a Bluetooth mouse uses a transmitter that communicates and connects with the Bluetooth receiver built into your computer .

If you want to use the wireless mouse in dom0, you can do something like:

echo "sys-usb dom0 ask,user=root,default_target=dom0" >>  /etc/qubes-rpc/policy/qubes.InputMouse

in a root shell from dom0.

I have debian as default template.
I installed (sudo apt install blueman -y) blueman within debian template.
I have blank tray icon(blueman-tray) to manage bluetooth now.
I’ve paired my mouse successfully, but keyboard doesn’t connect - it just says “failed to pair”.
When pairing the keyboard, I don’t get any visual output to type on the keyboard as it with other OS.

Also, when I restart my computer, the tray-icon sometimes appear and sometimes don’t.

Edit:
Also, when I switch computers with same bluetooth device, I keep getting the popup window saying: “Operation execution”, and then “source”(sys-net) and “operation”(dom0) to confirm.
I tried to make it as “trusted”, but it didn’t help.

What “trusted” mean, what does it do exactly?

You are so kind to post so quickly. This addition to the qubes.InputMouse policy worked for me. As for whether this is a wireless mouse or a bluetooth mouse, it is both. I understand what you are saying; I am using a kensington trackball that supports Bluetooth and also the little wireless dongle. I am happy having it work wither way, though certainly native bluetooth would be slightly nicer because then I would have no dongle hanging out in my USB A port.

I’d love any ideas on actually supporting a Bluetooth Low Energy mouse, but I am fairly happy with the dongle solution too, as it is quite close in my use case.

One other odd question for everyone: Logitech just released a new type of dongle (BOLT, or something like that) that appears to support more robust encryption. Any ideas on the security implications of that sort of setup vs Bluetooth Low Energy?

My thought would be that the Operation Execution window you are getting is the Qubes.MouseInput policy asking each time you try to activate the mouse/keyboard. In order to change that, you would likely need to edit your policy file as ChrisA suggested above for me, except you would need to substitute “allow” where it says “ask”. This is simply my hypothesis, mind you. I am not an expert on this OS by any stretch yet :-). I edited my policy file with the text editor “nano”, but the echo method ChrisA suggested should overwrite and replace the file that is currently there, I believe (someone please correct me if I am wrong!).

@grayman One other thing I should note as I have looked at solutions on these forums: you will probably get some pushback on supporting a bluetooth keyboard because of the security implications of that. A bluetooth mouse, to my understanding, is fairly safe because it has no ability to “see” or sense anything useful. A bluetooth keyboard, on the other hand, receives all your keystrokes, up to and including passwords you may type, so a security breach there is a critical one. I would also advise against it on those grounds. However, I also believe that your computer is yours as is what you choose to do with it, so just be aware of that (fairly huge, though hopefully unlikely) danger. Each person has a different life and different needs, so I would certainly help you out there if I knew how (once I had given my warning), but I can’t even get the bluetooth service to run on my sys-net (fedora based) so far…

If you use:

echo "sys-usb dom0 ask,user=root,default_target=dom0" >>  /etc/qubes-rpc/policy/qubes.InputMouse

you’ll append (>>) to the current file - if you use

echo "sys-usb dom0 ask,user=root,default_target=dom0" >  /etc/qubes-rpc/policy/qubes.InputMouse

you’ll overwrite and replace the file (>) … so pay attention - Linux will do what you ask to the letter! :wink:

1 Like

The “allow” instead of “ask” doesn’t do the trick.
I still need to setup(pair) mouse after re-boot.
It doesn’t solve the keyboard problem whatsoever.

Any relevant help, please?

When using “allow”, the “default_target” part should be deleted. Or the policy is wrong in format.

You’re correct, thanks. Can you share where did you find this info in the docs, I couldn’t find it.

However, I still need to redo the whole pairing process even if I “trust” the device and use the “allow” as stated above.
I assume it’s due to the nature of the sys-* being disposable? Are there any practical solutions to this, please?

Frankly, I didn’t find where the docs explicitly mentioned this info. I got this info based on my observing of the policy examples in the docs.

I think so. You may reference those posts that use a disposable sys-net and want to keep wifi passwords. You can also try finding where blueman stores its configurations, thus the confs can be preserved across disposable reboots.

I think I have figured out how to resolve your issue there, by playing around with my system. It is definitely about the issue of sys-* being AppVMs. So what I was able to do to permanently pair a bluetooth mouse is to pair it in the TemplateVM itself. Obviously, do this cautiously as the TemplateVM is meant to be quite trusted in your system. You could even clone your template VM (fedora or debian) and then use the cloned template to make the needed modification and base your sys-USB on that one if you care to be a bit more secure.

Either way, I had to temporarily connect my template VM to my USB controllers and bluetooth card (which requires that you set the template as HVM. Be sure to change it back after you are done!). Then boot the Template up. You may have an issue of an error where the USB controller cannot reset by force, in which case you can check the box for each controller device to allow it to boot without reset. This would be done most safely as soon as you first start your computer so it is less likely you have any compromised hardware, but can be done anytime technically. Once you have booted, run the Bluetooth Adapter software (which you can enable by selecting that App in the VM Applications menu), this will ask if you should boot bluetooth at startup. You will want to say “yes”, I expect. Then run the Bluetooth manager (Blueman) and pair your device. Then trust it. Make sure it works, but then you should be able to shut down the template, remove the hardware connections and turn it back into a PVH Machine. Then reboot Sys-USB and/or sys-net and your bluetooth should work.

Yo… jesus christ, can someone plz just tell me how do I enable bluetooth keyboard in here? I did enabled my mouse, but ffs, there’s no info anywhere regarding keyboard… I know the risks, just tell me what to do to enable it, please

After some more months of experience with this OS I believe I can indeed answer your question. I have not tried this myself as I don’t need to use a bluetooth keyboard in my use-case, but I believe that QubesOS has not specifically blocked the ability to use one. In order to set this up, I believe it should be the same process as with your Bluetooth Mouse, but with one final difference: You will notice above that in order to make the mouse work in dom0, you needed to modify the file at

/etc/qubes-rpc/policy/qubes.InputMouse

If you navigate to that directory in a dom0 terminal cd /etc/qubes-rpc/policy/ and list the contents using ls, you will see that there is also a file there called qubes.InputKeyboard. I believe that file needs to be modified just like the mouse file needed to be to tell QubesOS to accept the keyboard under certain conditions. In total, I would suggest the following process:

  1. Temporarily connect bluetooth hardware (usually wifi card) and possibly USB controller to the Template VM of your sys-usb VM (need to change the Template to HVM probably to do this)

  2. Run Template VM and pair the device (keyboard or mouse)

  3. Open the Qubes RPC policy file and tell it to ask when it detects the Input Device being connected. I like to do this in nano, since I am not a Linux Veteran yet. sudo nano /etc/qubes-rpc/policy/qubes.InputKeyboard . Although you certainly do as suggested just above using echo, if you prefer.

  4. Add the following line to the top of the file sys-usb dom0 ask,user=root,default_target=dom0, and I personally keep the second line as it already is just in case it is helpful to deny any other cases that I don’t approve $anyvm $anyvm deny.

  5. Save the file and exit nano. Also, Make certain to remove the Bluetooth and USB controllers from the TemplateVM once you have paired the keyboard or mouse, and convert it make to PVH mode if changed.

Let me know if this works for you. I haven’t tried and I probably won’t, but if your use-case requires the keyboard, then I hope this helps!

1 Like