search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
534 stars 46 forks source link

CTAP Proxy Qrexec call destination should be @default for multiple USB qubes usage #8586

Open ben-grande opened 11 months ago

ben-grande commented 11 months ago

How to file a helpful issue

The problem you're addressing (if any)

The service qubes.UpdatesProxy uses @default as the destination and sys-net for target= 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:

ctap.ClientPin * @anyvm @default allow target=sys-usb user=root
ctap.ClientPin * @anyvm @anyvm deny

ctap.GetInfo * @anyvm @default allow target=sys-usb user=root
ctap.GetInfo * @anyvm @anyvm deny

u2f.Authenticate * @anyvm @default allow target=sys-usb user=root
u2f.Authenticate * @anyvm @anyvm deny

u2f.Register * @anyvm @default allow target=sys-usb user=root
u2f.Register * @anyvm @anyvm deny

If user has multiple USB qubes, the user can use a policy with a lower number also using @default as destination and change the target= parameter. Example:

ctap.ClientPin +arg @tag:u2f-trusted @default allow target=sys-usb-left user=root
ctap.ClientPin * @anyvm @anyvm deny

ctap.GetInfo +arg @tag:u2f-trusted @default allow target=sys-usb-left user=root
ctap.GetInfo * @anyvm @anyvm deny

u2f.Authenticate +arg @tag:u2f-trusted @default allow target=sys-usb-left user=root
u2f.Authenticate * @anyvm @anyvm deny

u2f.Register +arg @tag:u2f-trusted @default allow target=sys-usb-left user=root
u2f.Register * @anyvm @anyvm deny

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.

marmarek commented 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.

euidzero commented 11 months ago

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 ?

marmarek commented 11 months ago

Yes, in 4.2 you can configure it with "qubes global config", including enabling/disabling it per-qube - it will setup appropriate qrexec policy.

euidzero commented 11 months ago

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.

Example

What would be the proper workflow then ? Allowing any argument and having a "lock after first successful authentication" mechanism ?

marmarek commented 11 months ago

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...

euidzero commented 11 months ago

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.

ben-grande commented 8 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.

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 usbvms to be listed is: