qubes-app-u2f build and package qu2f_proxy for dom0

[manuelschneider]

The problem you're addressing (if any) Please correct me if I'm wrong: Currently it is impossible to use u2f-tokens in dom0. For example if one would like to use Yubikeys "Security Key" with the pam_u2f module for locking and login.

Describe the solution you'd like qubes-dom0-update qubes-u2f[-proxy] :)

Additional context I actually got qu2f_proxy to work in dom0 with a systemd-unit and by replacing qrexec-client-vm with `qvm-run -u root -p --service --nogui'. So I guess the effort is mostly packaging and parameterizing the call.

[andrewdavidwong]

Have you read these documentation pages?

• https://www.qubes-os.org/doc/u2f-proxy/
• https://www.qubes-os.org/doc/yubi-key/

Possibly related: #4661

[manuelschneider]

Yes I have.

As I understand it, the yubikey packages in qubes (the second link) are primarily for the "standard" Yubikey, it doesn't apply to the security series, as this only supports FIDO2 and U2F. The security series provides the option to have a hardware token without radio (NFC), which might be a security advantage in some scenarios.

The docs for u2f-proxy are well written for the case that you want to use u2f in a qube != dom0. #4661 probably helped there. Also, if you have a look at the rpm-spec for the dom0 package: There is no qu2f_proxy.

If you approve the solution I proposed above, I'd like to create a pull request within the next weeks.

[marmarek]

Generally a good idea. I've even tried exactly this setup before. It was kind of slow (over 1s before u2f token start blinking) though.

Technically, I was thinking about more generic solution - a qrexec-client-vm in dom0 as a wrapper to qrexec-client.

[manuelschneider]

That's exactly why I asked :) Thank you!

I'll have a look at qrexec-client-vm as soon as I have some spare time. Probably next week.

[manuelschneider]

qrexec-client-vm as python script in qubes-core-admin-client/qubesadmin/tools seems doable to me. However, I'm not sure if it will be much faster with the u2f token. I tried with

"qrexec-client", "-T", "-t", "-d", "self.vmname", "none:QUBESRPC", rpcname, "dom0"

directly, and I cannot tell if there is a difference. In any case the delay seems acceptable to me.

As I'm fairly new to Qubes I'm not sure about the argument mapping. I'd call QubesLocal.run_service with

• target_vmname -> dest
• program_ident -> service
• local_program + local_program_arguments -> localcmd

Ignored:

• --buffer-size

Hardcoded:

• user -> none
• wait -> true
• filter_esc -> true

Is that sufficient for most use-cases of qrexec-client-vm?

I guess another option would be to re-implement qrexec-client-vm for dom0. However, I'm really not sure this is worth the effort.

What do you think?

[marmarek]

qrexec-client-vm as python script in qubes-core-admin-client/qubesadmin/tools seems doable to me.

That wouldn't work, as qubes-core-admin-client may be installed in a VM too and it would conflict with real qrexec-client-vm there. qubes-core-qrexec/daemon (next to qrexec-client) would be a better place.

* user -> none

This should be DEFAULT

* filter_esc -> true

This should depend on whether localcmd is set and if stdout is a tty (see qvm-run logic). Especially hardcoding to true most likely will break service calls using binary protocol.

• target_vmname -> dest

• program_ident -> service

• local_program + local_program_arguments -> localcmd

Yes, this is right.

I'd call QubesLocal.run_service with

And also actually wait for it to finish. And set stdin/stdout/stderr (if no localcmd is set) - otherwise it won't be connected to actual stdin/out/err.