There used to be a doc talking about the qubes-u2f proxy. Now that doc seems to have been rewritten for the qubes-ctap proxy.
When I go to install qubes-u2f in a template, it says it’ll be installing qubes-ctap. But I was in another post and one of the devs said they were two separate programs. So which one is it? Has u2f been renamed?
Also, I’m new to 4.2. The new usb page in the Global Config mentions qubes-u2f needing to be installed in sys-usb. So does that mean it comes preinstalled in dom0 now? And again, it’s mentioning qubes-u2f, not qubes-ctap.
I’m sure this has been talked about somewhere but I can’t seem to find a straight answer for this.
Once that’s sorted, I have another question about the proxy. The docs still say that if you want to have verification based on what each qube has signed, you have to go in and do that on your own. But the writeup inside qubes 4.2’s new usb section says that it’s set up by default.
Again, which one is it? And if it’s the default, how to I disable that option? The docs only talk about how to enable it.
The Qubes U2F Proxy tool can be installed in Qubes 3.2 and 4.0. (However, the Advanced usage features are only available in 4.0.) These instructions assume that there is a sys-usb qube that holds the USB stack, which is the default configuration in most Qubes OS installations.
In dom0:
$ sudo qubes-dom0-update qubes-u2f-dom0
$ qvm-service --enable work qubes-u2f-proxy
In Fedora TemplateVMs:
$ sudo dnf install qubes-u2f
In Debian TemplateVMs:
$ sudo apt install qubes-u2f
Repeat qvm-service --enable (or do this in VM settings → Services in the Qube Manager) for all qubes that should have the proxy enabled. As usual with software updates, shut down the templates after installation, then restart sys-usb and all qubes that use the proxy. After that, you may use your U2F token (but see Browser support below).
I’m guessing CTAP proxy may be for other types of keys that are not U2f.
sudo apt install qubes-u2f package is still there on debian-12 Fedora-39.
Don’t know what you are “signing” in Q Global config, you register the U2f proxy to work either qube by app qube, or “all qubes” ; however you allow access to the keys on the token also qube by qube.
Awesome. That makes things a lot clearer. But the last questioner had a very good point.
I also mostly use disposable VMs with a lot of my accounts. So have they come up with a solution for this? They mentioned a selection menu with the individual keys.
I’m sure just installing it and playing with it will answer some of these questions but I’d like to know what I’m getting into.
# Installed qubes-ctap-dom0
sudo qubes-dom0-update qubes-ctap-dom0
# Enabled the qubes-ctap-proxy service in the work AppVM
qvm-service --enable work qubes-ctap-proxy
# Configured per-qube key access
echo "policy.RegisterArgument +u2f.Authenticate sys-usb @anyvm allow target=dom0" > /etc/qubes/policy.d/30-user-ctapproxy.policy
Installed qubes-ctap in the TemplateVMs upstream of my sys-usb and work AppVMs
I restarted sys-usb and work however, I could not locate Dom0’s /etc/qubes-rpc/policy/u2f.Authenticate file, which seems to be where the qube-to-key mapping would be configured.
I found that I had to add the following to /etc/qubes/policy.d/50-config-u2f.policy or my screen would be flooded with denied u2f authentication notifications
u2f.Authenticate * work sys-usb allow
Of note, it is better to configure this in the GUI to prevent the GUI from overwriting the settings via Global Config → USB Devices → U2F devices
Though this necessary modification resolves the flood of deny notifications and enables security key access, without the /etc/qubes-rpc/policy/u2f.Authenticate I don’t see how we’re actually limiting or specifying which qubes can access specific keys as described in the video above or documentation
I even registered a security key from the work AppVM, but the u2f.Authenticate file never materialized in Dom0.
Inferring from the rest of the documentation (namely the service name from the Non-default USB qube name section and the targeting of Dom0 in /etc/qubes/policy.d/30-user-ctapproxy.policy, I looked to see if Dom0 had any services with ctap in the name via systemctl list-units|grep ctap, but couldn’t find anything.
It seems better to store U2F/CTAP policies in dom0’s /etc/qubes/policy.d/30-user-ctapproxy.policy RATHER THAN /etc/qubes/policy.d/50-config-u2f.policy to prevent the GUI from overwriting any custom policies
Some websites seem to trigger notifications related to ctap.GetInfo and ctap.ClientPin, so consider adding policies to account for this. The resultant dom0 /etc/qubes/policy.d/30-user-ctapproxy.policy might look like
u2f.Authenticate * work sys-usb allow
ctap.GetInfo * work sys-usb allow
ctap.ClientPin * work sys-usb allow
