Open ben-grande opened 11 months ago
In 4.2 the CTAP policy is managed by the global config tool, and default you pointed out is not included anymore, so the policy change would need to be there.
But generally, I agree this is a very good idea. The problem with this is such change will break the proxy for users who already use it. I guess we can schedule it for Qubes 5.0, or maybe 4.3 if we figure out how to reliably convert the configuration during upgrade.
Is it expected that no specific policy for u2f.Authenticate, ctap.ClientPin and ctap.GetInfo exists in 4.2 after an upgrade for 4.1 ?
Yes, in 4.2 you can configure it with "qubes global config", including enabling/disabling it per-qube - it will setup appropriate qrexec policy.
There's a catch in having only the 60-registered-arguments.policy : with the generalization of passkey, if one did not registered a specific passkey from qubes then trying to access a passkey protected site trigger a flood of popups from qrexec, blocking the entire screen.
What would be the proper workflow then ? Allowing any argument and having a "lock after first successful authentication" mechanism ?
It's getting offtopic in this issue. But indeed, there is no GUI for configuring keys generated elsewhere right now, for that you can edit policy manually (we have GUI policy editor now, that validates it before saving). You can get key hash from logs...
Yes, in 4.2 you can configure it with "qubes global config", including enabling/disabling it per-qube - it will setup appropriate qrexec policy.
Starting from no configured access to u2-proxy, editing with the Gobal config tool only created policies for u2f.Register and u2f.Authenticate. Nothing for ctap.ClientPin not ctap.getInfo.
In 4.2 the CTAP policy is managed by the global config tool, and default you pointed out is not included anymore, so the policy change would need to be there.
But generally, I agree this is a very good idea. The problem with this is such change will break the proxy for users who already use it. I guess we can schedule it for Qubes 5.0, or maybe 4.3 if we figure out how to reliably convert the configuration during upgrade.
What about no conversion policy side? Just setting a default policy that covers both cases? Works with either qubes-ctapproxy@sys-usb
or qubes-ctapproxy@@default
service enabled:
ctap.GetInfo * @anyvm sys-usb ask default_target=sys-usb user=root
ctap.GetInfo * @anyvm @default ask default_target=sys-usb user=root
As an example, what I am using with 3 sys-usb allowing users to tag different usbvm
s to be listed is:
User policy:
ctap.GetInfo * @anyvm @tag:usbvm ask default_target=sys-usb-dock user=root
ctap.GetInfo * @anyvm @default ask default_target=sys-usb-dock user=root
Default policy:
ctap.GetInfo * @anyvm @tag:usbvm ask default_target=sys-usb user=root
ctap.GetInfo * @anyvm @default ask default_target=sys-usb user=root
How to file a helpful issue
The problem you're addressing (if any)
The service
qubes.UpdatesProxy
uses@default
as the destination andsys-net
fortarget=
parameter. This is very useful in case you have multiple ones, you can redirect simply by policy without having to manipulate VM services.The solution you'd like
For people with multiple USB controlers and multiple USB qubes, the following would be useful.
My proposal is for
qubes-ctapproxy.service
and the Qrexec policies to use:If user has multiple USB qubes, the user can use a policy with a lower number also using
@default
as destination and change thetarget=
parameter. Example:What needs to be changed:
The value to a user, and who that user might be
User with multiple USB controlers and USB qubes won't have to do in App qube settings in
/rw/config/rc.local
or Template VM enabling the service to a specified sys-usb qube in there.The management of multiple sys-usbs will become easier and will follow the convention that is on
qubes.UpdatesProxy
, which is a good practice.