U2Fproxy reports 'Permission Denied' for action qrexec: policy.RegisterArgument+u2fArgument+u2f.Authenticate yet it works

mig5 commented 2 years ago

Qubes OS release

4.1

Brief summary

I just installed the U2F proxy service in dom0 and the Debian 11 template. I have a sys-usb with my Yubikey 5 NFC attached.

I have enabled and am running the Qubes U2F service in a dispVM (also based on Debian 11).

I registered my Yubikey with Github as well as other services such as Google. Each time I go through the registration of the key, I get a popup notification about Permission Denied for the policy.RegisterArgument+u2fArgument+u2f.Authenticate qrexec.

I also see this in the dom0 journalctl:

qrexec-policy-daemon[2210]: qrexec: u2f.Register+: disp3907 -> sys-usb: allowed to sys-usb
qrexec-policy-daemon[2210]: qrexec: u2f.Register+: disp3907 -> sys-usb: allowed to sys-usb
qrexec-policy-daemon[2210]: qrexec: policy.RegisterArgument+u2fArgument+u2f.Authenticate: sys-usb -> disp3907: denied: denied by policy /etc/qubes/policy.d/90-default.policy:14

Indeed on line 14 I have:

policy.RegisterArgument * @anyvm @anyvm deny

So no big surprise there.

What I am confused about, though, is that the registration seemed to work. Github, Google etc happily accept my security key and I can login with them (I even used it to login to Github to file this report).

So my question is: is it a harmless bug? Or is it worth modifying the policy nonetheless? Alternatively, if it's not necessary for registration, is the default policy actually not doing its job?

Steps to reproduce

Install u2f proxy per https://www.qubes-os.org/doc/u2f-proxy/ on Qubes 4.1 (don't do any of the 'Advanced Usage' steps, just the Installation section).

Register a Yubikey 5 NFC with a 3rd party service that supports it (Github, Google).

Expected behavior

I should not get any permission error given that my registration seemed successful

Actual behavior

I get the above permission denied message and log entry, yet everything seems to still work

woju commented 2 years ago

So my question is: is it a harmless bug? Or is it worth modifying the policy nonetheless? Alternatively, if it's not necessary for registration, is the default policy actually not doing its job?

This is harmless, and a part of mechanism for optional per-qube registration:

https://github.com/QubesOS/qubes-app-u2f#advanced-per-qube-access-enforced-by-policy

The link describes how you can redo the (old version) of the policy, so that a credential provisioned in one qube cannot be used to authenticate by another qube (most tokens don't display what app you're authenticating to, so if two authentications are in progress simulateneously, you have no way to know, which one you're approving by clicking the button on the token).

By default we don't do this per-qube isolation, because if you don't know about it and attempted to use token from other qube, it would be broken with no obvious way to fix, and there are legitimate setups when you actually need to use one credential in multiple vms. But the policy call is always attempted, because usbvm has no way to know how you configured your policy.

@andrewdavidwong README in qubes-app-u2f could use an update to new policy. Otherwise, I don't think there's anything actionable here.

DemiMarie commented 2 years ago

@woju I was actually assuming that the per-qube isolation was on by default, and was rather shocked that it was not.

andrewdavidwong commented 2 years ago

@andrewdavidwong README in qubes-app-u2f could use an update to new policy. Otherwise, I don't think there's anything actionable here.

Understood, thanks. Reclassified as a documentation issue and reassigned to you for the README update. (I noticed that you're the only one in its commit history, so figured you know it best.) But please feel free to unassign yourself or reassign to someone else if there is someone better suited to do it.

QubesOS / qubes-issues