Open rugk opened 5 years ago
rugk
commented
4 years ago Any official reply? Are you evaluating this or what?
4 users have already upvoted this, and the issues that it causes come up again and again. And as I think the prevalence of WebAuthn/hardware keys or similar will only increase in the future, this topic/problem will likely come up/get bigger again and again.
rugk
commented
4 years ago Cross-posted to the GNOME Discourse forum.
TingPing
commented
4 years ago Since you seem quite passionate about this portal its likely going to come down to implementing it yourself.
rugk
commented
4 years ago If you look at https://github.com/QubesOS/qubes-app-u2f you'll see this may certainly not be easy.
TingPing
commented
4 years ago I did glance over it and yeah it is very complex. I'm not super familiar with U2F but it seems deeply tied to USB which makes things harder.
swick
commented
4 years ago I'm also interested but have not looked much into it. Does the browser have to use the CTAP spec? Can we not "just" have a daemon on the host talking CTAP with the devices and expose a simpler, more WebAuth-like API through a portal?
ueno
commented
4 years ago Hi Sebastian, that sounds reasonable. I have recently been working with a student who is trying to expose CTAP2 through D-Bus for similar purposes, and asked the developer of authenticator-rs about the possibility of future integration; adding it as an alternative transport seems to be an option, once the multiple transport support is implemented in the library.
That said, we haven't even figured out how the D-Bus protocol would look like. Perhaps we could collaborate on the design and implementation? :-)
rugk
commented
4 years ago BTW with the official release of a Firefox flatpak on Flathub, this is getting much more important now. :smiley:
barthalion
commented
4 years ago At the moment it works as long as you have udev rules for your U2F device installed on the host. Firefox uses --device=all and my Yubikey works fine that way.
WayeeCool
commented
4 years ago Came here because I gave the official release of Firefox for Flapak a try only to discover that U2F and webauth are broken with zero plans for a fix. I am seriously disappointed and rather surprised to see core Gnome and Flatpak devs dismissively claiming that this is not a critical feature for Flatpak to be considered usable for mainstream desktop use.
The "efff off" answer to bug reports and feature request on this topic rather than maybe suggesting a feature bounty, really says something about the management of the Flatpak project and probably shines light on the platforms adoption issues. How can Flatpak's developers argue that Flakpak is better than traditional methods of application distribution "because it promotes security" when they are also claiming security critical application features such as U2F/webauth have no place?
swick
commented
4 years ago That said, we haven't even figured out how the D-Bus protocol would look like. Perhaps we could collaborate on the design and implementation? :-)
I'm afraid that I can't help much with that without diving into the protocols but it should not be too hard when you already have a solid, simple C interface.
AlfioEmanueleFresta
commented
4 years ago I agree - we certainly need a portal for FIDO authentication. However, I think this should expose the new FIDO2 interface, rather than CTAP. FIDO2 is a relatively simple API, and it can be used with CTAP2 authenticators, platform authenticators, and can also be mapped to CTAP1 U2F following the WebAuthn spec.
There is precedent for this approach on other platforms, including Android's Fido2ApiClient and the Windows Hello FIDO2 Win32 API.
Furthermore, a FIDO2 portal API would also enable another very important missing bit of functionality: platform authenticators. Think of Windows Hello's built-in authenticator - I believe this would be instrumental for the shift to passwordless authentication.
I have started working on a proposal for a new FIDO2 portal, xdg-credentials-portal. I would like to start with a D-Bus portal API specification, and FIDO U2F (CTAP1) support, backed by authenticator-rs. Please get in touch if you'd like to contribute, or if you have any feedback.
ueno
commented
4 years ago This looks like a great start! A couple of things I would like to suggest are:
swick
commented
4 years ago @AlfioEmanueleFresta I believe it would be better to separate this into two projects:
This has several advantages e.g. we could use the system service to implement a pam module, replace it with another implementation and make slightly different APIs for privileged clients (using the system service) and unprivileged clients (using the portal).
* you say FIDO2 API but afaik FIDO2 is actually two APIs: WebAutn and CTAP2
AlfioEmanueleFresta
commented
4 years ago Thanks for your feedback @ueno, @swick.
We probably want to avoid re-serializing RPC [...]
A WebAuth-like D-Bus interface is probably ideal for this. authenticator-rs has a similar high-level API (FIDO U2F), and takes care of CTAP1 encoding internally. For FIDO2 devices, authenticator-rs, or the BLE/NFC components, would be responsible for CTAP2 serialisation.
The portal should be able to provide access control per device; [...]
This is the intended behaviour for a WebAuthn call:
@ueno Does this sound reasonable? Are there any security concerns which aren't addressed by this, and would require explicit per-device permissions, or even require permissions for applications access the API?
I believe that by exposing a Webauthn-like interface via D-Bus, device enumeration functionality would not need to be exposed to client applications, either for permissions, nor pairing/user selection purposes.
Devices would still require a gesture from the user. Most importantly, I believe this to be the current behaviour of authenticator-rs, which does not expose any device enumeration functionality to its consumers - hence changing this may significantly increase the complexity. The parsed contents of the CTAP response, without device metadata would be returned to the sandboxed application.
BLE would be easier - the application would still not have access to devices, and the platform would be responsible for listing, and pairing, available authenticators. This adds a bit of complexity in terms of UI (Chrome on Mac, and Windows Hello both do this, see example screenshot). authenticator-rs does not currently support BLE authenticators. I believe the easiest way to implement this would be using BlueZ's BLE D-Bus API, which does most of the heavy lifting (searching, pairing, listing available and paired devices, BLE GATT functionality).
I believe it would be better to separate this into two projects [...]
@swick I completely agree the new service should eventually be fronted by xdg-desktop-portal.
With regards to having different APIs for different privilege levels (e.g. a D-Bus API and a system service), I'm not yet convinced.
In fact, what Android calls the their privileged API could be made available to all applications, as long as the confirmation dialog is displayed (e.g. Firefox would like to create new credentials for example.org: [...]).
If in the future we crack how to verify associations between origins and the D-Bus API caller, we could introduce the unprivileged API, possibly skipping the confirmation dialog, eg. say the Spotify app tried to create credentials using the verified "spotify.com" origin. However, I have my doubts we would ever be able to verify this, as the Android approach relies on trusting the Play Store to verify the association on behalf of the user.
With phones soon becoming CTAP2/caBLE authenticators for the masses, I think the BLE transport will eventually become more important than U2F/USB. It appears the current best practice for new BLE applications, is to use the BlueZ D-Bus API, which in turn means the system component would also interact with D-Bus. I'm not yet sold on the advantages making the service a system service, resulting in an additional abstraction layer.
- you say FIDO2 API but afaik FIDO2 is actually two APIs: WebAutn and CTAP2
You're right. I have to admit I like Google's choice to use FIDO2 to refer to the public API, (Fido2ApiClient), but it may be more accurate to use WebAuthn for naming purposes.
swick
commented
4 years ago Currently reading through the WebAuthn and CTAP2 specs but that will take some time so I probably have more to say later.
With regards to having different APIs for different privilege levels (e.g. a D-Bus API and a system service), I'm not yet convinced.
When the portal API is used the user interface for the ceremony is provided by the portal backend. When we want to use the same API in a login managed to log a user in (i.e. we don't have a user session and no portals yet) how would that work? Same question for the portal backends: how are they supposed to show you a user interface?
We need to provide some API to those things that allows them to create user interfaces and we can not provide portal users the same API because it gives them information they should not have.
(we really should give those two APIs names. Maybe the platform API and the portal API)
I think you just assumed the platform API to simply be the authenticator-rs API. IMO that would be a mistake because we want to support system authenticators and things like that. How to expose the API I'm really not sure. Just a shared object, system daemon, user session daemon?
In fact, what Android calls the their privileged API could be made available to all applications, as long as the confirmation dialog is displayed (e.g. Firefox would like to create new credentials for example.org: [...]).
That wasn't what I meant with privileged API but it's a good point nevertheless. I don't fully understand why there is two APIs for Android. The only difference seems to be that the privileged one allows you to set the origin. What is the origin in the unprivileged version?
AlfioEmanueleFresta
commented
4 years ago Got it. Here's a summary, as revised:
The reason why I believe transport enumeration and transport-specific APIs are required, is that transports have drastically different characteristics:
How to expose the [platform] API I'm really not sure. Just a shared object, system daemon, user session daemon?
I will note there is at least one transport which may involve user-specific authenticators: Android phones as CTAP2 over cloud-assisted BLE (caBLE). Unfortunately the spec hasn't been published yet. Additionally, whilst I believe BLE devices are paired to the system's adapter, it may desirable to only show users authenticator devices they've paired themselves (and decouple the concepts of authenticator pairing, and BLE/physical pairing). I'm unsure as to whether this is a point in favour of an user-session daemon, or simply a 'user' parameter for a system daemon/library.
I don't have any strong opinions on library vs daemon. I am now leaning towards a D-Bus daemon, as I've just learned about the Linux NFC D-Bus APIs. This is in addition to the BlueZ GATT D-Bus APIs I've already mentioned for BLE authenticators. Finally, D-Bus introspection (listing available interfaces on a well-known object) would make for a very elegant transport enumeration system.
I don't fully understand why there is two APIs for Android. The only difference seems to be that the privileged one allows you to set the origin. What is the origin in the unprivileged version?
To access the unprivileged API, native Android applications need to declare an origin value within the app manifest, and prove they control the origin by serving a file on their website (the app store verifies the file on behalf of the user).
Accessing the privileged API allows specifying arbitrary origins. However I believe it requires submitting a request for human review to the Play store, to certify the app as a web browser.
swick
commented
4 years ago Sounds good! Thanks for explaining how it works on Android. I've noticed a few more things…
Does it make sense?
GeorgesStavracas
commented
1 year ago GeorgesStavracas
commented
1 year ago Actually, let's do the opposite - mark https://github.com/flatpak/xdg-desktop-portal/issues/987 as duplicate of this one
GeorgesStavracas
commented
1 year ago @AlfioEmanueleFresta I did not notice this issue, as it was in the Flatpak repository instead of xdg-desktop-portal. What was the reason for you to create a separate portal daemon for that? Experimentation? (Also, sorry to be a pain, could you please rename it to something else without the xdg- prefix? It's abundantly clear that it wasn't your intention, but it accidentally impersonated the XDG group!)
Seems like it's not controversial to put these portal interfaces in xdg-desktop-portal. Do you think you can open a pull request with the D-Bus interfaces you came up with, and an implementation for them? I'm afraid I cannot provide commentary on the inner workings of such portals, there's people around much more accomplished than I am in this domain, but I'll be happy to provide a high-level review on the APIs themselves to help make them compatible with portal API design. I haven't looked at the D-Bus interfaces on your repository.
mcatanzaro
commented
1 year ago Do we really need to expose U2F support? That is a legacy protocol. I think we should just expose what's needed for FIDO2/CTAP/WebAuthn and forget about U2F.
GlenKPeterson
commented
1 year ago device=all is a great workaround. I enabled this for my webcam, but it works for my Yubikey on Ubuntu 22.04 with snap removed and flatpak installed. Thank you!
baloo
commented
1 year ago Do we really need to expose U2F support? That is a legacy protocol. I think we should just expose what's needed for FIDO2/CTAP/WebAuthn and forget about U2F.
Generally agree on that, but, if websites had shipped with u2f initially, that should keep working. The portal should still do the switch between CTAP2 (roughly (don't know if it's the right term) FIDO2 message encoding) and CTAP (FIDO1 message encoding) to keep retro compatibility with existing devices. If I remember correctly, that's a matter of querying the capabilities when opening the device and then continue with the correct protocol.
ueno
commented
1 year ago My earlier comments are from 3 years ago, but let me add some notes when we tried to make CTAP2 devices accessible through a portal (it was an internship project of my then-student and the snapshot is kept here):
Request objectLD_PRELOAD as in umockdev, but I guess it's not the way to go. We need some abstraction at client side, either based on D-Bus or shared library (or whatever)C_GenerateKeyPair, C_WrapKey, C_Sign*, etc.mcatanzaro
commented
1 year ago It might be possible to define a PKCS#11 like shared library providing those two operations and make browsers dynamically load and use it; OpenSSH's sk module might be a good candidate, or perhaps we could translate the operations into PKCS#11 C_GenerateKeyPair, C_WrapKey, C_Sign*, etc.
Is this really easier than just changing the Firefox build to not block networking calls? WebKit's preference would definitely be to use D-Bus rather than add a new dependency.
ueno
commented
1 year ago I can't say which one is easier without further research, but if a single framework could handle both FIDO2 and smartcard authentication, that would be a huge win and the transition would be smoother.
ItsJamie9494
commented
1 year ago It's been a few months with no update from @AlfioEmanueleFresta, any plans on where to go from here, or do we want to keep waiting
swick
commented
1 year ago I'm all for implementing a portal right now and use libfido2 or whatever else in the backend until we have a better solution.
jadahl
commented
1 year ago Sounds like a sane idea to just start with libfido2; just need to be careful and consider when we need an external service that handles the low level things, as an external repo/project, and move the any implementation we start in xdp there and have xdp consume it via D-Bus instead. The point for that being to let xdp be as much of a dumb plumbed pipe it can for these kind of things.
ItsJamie9494
commented
1 year ago Sure, but for now, we can build it into xdp, just so we can get something working?
On Tue, 9 May 2023, at 07:56, Jonas Ådahl wrote:
Sounds like a sane idea to just start with libfido2; just need to be careful and consider when we need an external service that handles the low level things, as an external repo/project, and move the any implementation we start in xdp there and have xdp consume it via D-Bus instead. The point for that being to let xdp be as much of a dumb plumbed pipe it can for these kind of things.
— Reply to this email directly, view it on GitHub https://github.com/flatpak/xdg-desktop-portal/issues/989#issuecomment-1540301330, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFJ3XARJLAXHJOGNV72KNXDXFJLLFANCNFSM6AAAAAAWCMSVLI. You are receiving this because you are subscribed to this thread.Message ID: @.***>
mcatanzaro
commented
1 year ago I'm not sure whether having a separate service makes sense or not, but if that's what we want to do I bet it will be easier to start writing it that way from the beginning.
Here is my concern regarding an external service: what API do you want apps to use?
Just brainstorming. I understand if keeping xdp small is the more important consideration.
jadahl
commented
1 year ago My assumptions has been that apps should always target the xdp API no matter where they are. Maybe a "service" is indeed unneeded if all the actual cryptographic complexity lives outside in libfido2 etc, the idea for a (system) service was written here: https://github.com/flatpak/xdg-desktop-portal/issues/989#issuecomment-1477784997. Anyhow, I'd start thinking about the portal API and implementing that directly with e.g. libfido2 first to see if it works well.
ItsJamie9494
commented
1 year ago I believe the main reason we had an external service was because it would allow the system to benefit from the shared code?
ItsJamie9494
commented
1 year ago If we're in agreement to implement most of the code into xdp, I'll get started on something this week
swick
commented
1 year ago I can only speak for myself and still believe it's a good idea. There seem to be some reservations regarding how viable a portal will be to implement in firefox though.
pinkflames
commented
1 year ago Is there some problem with viewing XDG Desktop Portal as the API to use for the Linux platform? If so, Firefox may consider XDG desktop to be its own platform and target that instead. :wink:
ItsJamie9494
commented
1 year ago @swick that was why we were considering offering a portal on a separate service. However, for now, I think we should try and add it to xdp. If we find that it needs to be separate, we can separate it later. Let’s stick with what’s established for right now
jadahl
commented
1 year ago There seem to be some reservations regarding how viable a portal will be to implement in firefox though.
Got some bugzilla link or something about this? Firefox already depends on portals for some things, so don't get why it couldn't use it for more.
swick
commented
1 year ago Just something I've been told. I have no better information here unfortunately. I'm still all for going ahead with the portal fwiw and will try to help out as much as possible.
TingPing
commented
1 year ago I didn't see it mentioned here but this project also exists, though dead: https://gitlab.freedesktop.org/dueno/fido2-proxy
Personally I found xdg-credentials-portal more promising but I'm not sure of the details.
ueno
commented
1 year ago There seem to be some reservations regarding how viable a portal will be to implement in firefox though.
Got some bugzilla link or something about this? Firefox already depends on portals for some things, so don't get why it couldn't use it for more.
See the above comment https://github.com/flatpak/xdg-desktop-portal/issues/989#issuecomment-1480574134. The 4th bullet point provides a link (note that Firefox's FIDO support goes through authenticator-rs, in case it is not clear). Here is also a previous attempt to integrate the D-Bus service into Firefox.
ItsJamie9494
commented
1 year ago We can access portals through D-Bus, so I don't see that being an issue?
msirringhaus
commented
1 year ago Just to quickly chime in with a few links regarding Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1827410 https://bugzilla.mozilla.org/show_bug.cgi?id=1530370#c36
There is no explicit restriction to not use portals, as far as I know. And there is a lot of effort currently going on (including from myself) to have full CTAP2.1 support in auth-rs. So at least there is some active development going on in that area at the moment.
mcatanzaro
commented
1 year ago @AlfioEmanueleFresta if you're still around, your input here would be very valuable
mcatanzaro
commented
1 year ago We can access portals through D-Bus, so I don't see that being an issue?
If Firefox blocks Rust code from making networking calls, then that's presumably also going to block D-Bus and most other forms of IPC. Of course that should not have any impact on how we design our APIs. Firefox should either not do that, or not use Rust for this.
ItsJamie9494
commented
1 year ago If they’re blocking networking requests, then any system API we create would most likely be blocked, so I see this as their bug and not a concern for usOn May 12, 2023, at 08:18, Michael Catanzaro @.***> wrote:
We can access portals through D-Bus, so I don't see that being an issue?
If Firefox blocks Rust code from making networking calls, then that's presumably also going to block D-Bus and most other forms of IPC. Of course that should not have any impact on how we design our APIs. Firefox should either not do that, or not use Rust for this.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
iinuwa
commented
11 months ago Is there a call to action here? From this thread I wasn't sure if someone from Red Hat/Gnome/Flatpak teams were going to take it from here, or whether this was still up for discussion.
I've been working on a platform authenticator implementation on Linux that sort of ties into this discussion. (It's very similar to the work that Daiki Ueno and Norbert Pocs did in fido2-proxy mentioned above.)
It seems that these are some of the open questions:
I think this comes down to . If portals can lookup the App ID of the caller (in case of Flatpaks; I assume in normal native apps, this is not a thing), then I don't think we need a separate API. We could allow all Flatpak apps to create/read credentials for all credentials in the beginning, and then we could later on enforce that the origin matches some origin derived from the app ID, returning a NotAllowedError if it doesn't. We could also use the same thing to support hosting manifests for other origins over HTTPS if we wanted, though I don't know realistically how many services would add new manifests for Flatpak/Linux users.
Should callers need to know CBOR? This can go either way, but I'm leaning toward passing CBOR data through. Attestation objects returned from created credentials are encoded in CBOR. From the limited persusal that I've done of a few client/server libraries, it seems that most libraries pass through the CBOR data straight through from the client (browser) to the relying party, which would do the CBOR decoding.
There are helper WebAuthn APIs that parse the CBOR data so that web developers don't have to parse it in JavaScript. If browsers want to parse the CBOR to implement those helper APIs, that's fine for them to do. For other non-browser native/Flatpak applications, passing through the CBOR data to the RP is probably sufficient.
This would mean that if we implemented a platform authenticator, we would need to CBOR-encode the attestation objects, but we will likely need a CBOR decoder anyway to support cross-platform authenticators, so I don't think that's a big deal.
This is what the Windows Hello/WebAuthn API does: https://github.com/microsoft/webauthn/blob/master/webauthn.h#L904
So far, I haven't seen a concrete D-Bus API design on this thread. @AlfioEmanueleFresta has some interface XML docs on his repo; would it be helpful if I formatted a design doc draft for critique? I think I could do that sometime in the next couple weeks.
Do we need transport enumeration in the portal API? I don't think so. FIDO2 Hybrid transports are intended to be implemented by the client platform. So the "transport selection dialog" shown in this comment is eventually going to go away from Chrome. macOS can already handle hybrid authenticators in the platform, and in Windows 23H2+, Windows Hello will handle the hybrid transport itself. If we want to support hybrid authenticators, then that should be in the portal implementation. (The CTAP 2.2 spec draft describes the hybrid transport method, so this could now be implemented in client platforms.)
Here's a point I'll add to the mix: do we want to leave the door open to support other credentials? We may want to model this portal after the w3C Credential Management API, which is what WebAuthn built on top off. This could allow the same API to be used to request/store both asymmetric (FIDO2) and symmetric (passwords) credentials, using the same framework/UX for user origin-based user consent. It could also resolve issues with standardizing password formats, as in gitlab.gnome.org/gnumdk/passbook/#17. Of course, to focus on FIDO2, we don't need to implement or even fully define the APIs for the other credential types, but it may be good to keep in mind while designing the FIDO2 methods
Are we going to be able to convince Mozilla to use a portal instead of their authenticator-rs library? (This could be opportunistic: if org.freedesktop.portal.Credential exists, then use that portal over D-Bus, else use authenticator-rs). Perhaps, if we can get a good adoption from distributions. The authenticator-rs work can be re-used in the portal implementation itself.
Providing the ability to login to the computer with locally registered FIDO2 credentials, a la Windows Hello and macOS's TouchID and FaceID, would be a neat feature. I think it's out of scope for this issue though. This relates more closely to a platform authenticator than to the portal itself. (Personally, I would love to tackle it though. :) )
Does that about sum things up? Should I work on a design document?
mcatanzaro
commented
11 months ago Does that about sum things up? Should I work on a design document?
Sounds like you are on the right track here. This would be helpful. Thanks!
Are we going to be able to convince Mozilla to use a portal instead of their authenticator-rs library?
I'm sure they'll ultimately use whatever API we define because (a) they want Firefox to work, and (b) Red Hat does much of the portal integration work anyway.
swick
commented
11 months ago Sounds great!
We could allow all Flatpak apps to create/read credentials for all credentials in the beginning, and then we could later on enforce that the origin matches some origin derived from the app ID, returning a NotAllowedError if it doesn't.
This is the only part I have a problem with. Going from an open to a restricted policy is going to break someones use case. However, this policy is really independent of the rest of the system so I'd say go ahead with your plan, and before we merge anything we should revisit this point.
IMHO what is missing as a todo item for the sandbox, is FIDO U2F/WebAuthn abstraction for USB devices.
Problem
User story: I, as a user of a flatpak'ed browser, want to be able to login with my cool U2F/WebAuthn keys, because they are very convenient & secure & with increased adoption I may also be able to use a passwordless authentication.
So one could do so when you enable the
--device=allpermission, but obviously (for isolation/sandboxing reasons, i.e. security reasons) one does not want to expose all USB devices to a browser application.WebAuthn spec has recently been finalized: https://www.w3.org/TR/webauthn/
Support for U2F/WebAuthn is available in major browsers like Firefox and Chrome/ium.
Proposed solution
Another special abstraction (and permission) for U2F/WebAuthn access.
Actually, the security and isolation-focused distro Qubes OS does already have developed a model, abstraction and even software that can be used in their distro to abstract that: https://www.qubes-os.org/doc/u2f-proxy/ source code: https://github.com/QubesOS/qubes-app-u2f
The doc is really worth a read!
So maybe some kind of new portal? Or new permission?
Also discussed at
Other useful links
https://en.wikipedia.org/wiki/Universal_2nd_Factor https://en.wikipedia.org/wiki/WebAuthn
(sponsored sites, but visibly nice) https://webauthn.guide/ https://webauthn.io/