Origin Checking

[iinuwa]

This issue depends on support that is not currently provided by any Linux desktop that I'm aware of.

Requirements

To securely control origin checking, we need two things

• application identity
• secure permission storage

Application Identity

Currently, the credential service does not verify that a particular application should be requesting credentials for a particular origin. In order to do this properly, the application must have some sort of identity that the credential service has access to.

As far as I know, we only have access to the path of the processes and any labels applied to the process/executable from Linux Security Modules (LSM) that provide mandatory access control (MAC), like AppArmor or SELinux).

Permission Storage

After identifying the application, we need a way to give permission to that specific application. If we're using some sort of signature-based, that permission could be hard-coded into the binary or corresponding package metadata. Alternatively, or in addition to that, we can also have the user provide consent for the application. That consent will need to be persisted to disk, where other applications could modify it. Only the credential service should need to modify this data, so using a MAC LSM again to only allow the credential service to modify this data should be sufficient.

Sandboxed vs. Unsandboxed applications

For sandboxed applications, the sandbox runtime can pass the application identifier (e.g. Flatpak ID). This requires implicit trust in the sandbox runtime and that the current call is actually being made by the sandbox runtime, and not another application spoofing it. This is the same problem as the application identity situation described above, but more constrained, as we could hard-code a few sandbox runtimes rather than every single application or Python script.

We can change some of these protections using compile-time features. For example, since Fedora has support for SELinux and RPMs, they could ship a version that uses SELinux and validates package signatures with Integrity Digest Cache based on the RPM packages, while Ubuntu could ship AppArmor support (and no package signature validation, since they don't include signatures in their package metadata).

Mapping application identity to origins

If an application does not have permission to set its own origin, we have to have some way to bind the application's ID, e.g. the Flatpak app ID, to the WebAuthn origin. Whatever we come up with will probably look something like the existing ecosystem for Android, macOS/iOS, and Windows (note, website/app binding is used for other purposes in Windows, but not WebAuthn). See also the related_applications field of W3C Web Applications Manifest Incubations spec, and this issue.

We should also look into how Related Origin Requests affects origin checking.

Hard mode

• sandboxed applications cannot set their own origin, unless they are given permission to access the credential portal for privileged applications. Sandbox runtime is responsible for verifying application integrity and provenance. The identity of the sandbox runtime itself is validated with LSM features.
• Unsandboxed application identities are verified with LSM features (Integrity Digest Cache, AppArmor/SELinux), and user gets a permission prompt to allow a specific application to request data for any origin on first use. The storage for the permission store is protected by an LSM so that it can only be changed by the credential service.

Easy Mode

• sandbox runtime paths are hard-coded into the app to trust IDs of sandboxed applications implicitly. Sandbox runtime is responsible for verifying application integrity and provenance. Sandbox runtime is responsible for verifying application integrity and provenance.
• unsandboxed applications can request whatever they want. Consent is stored via xdg-permission-store