PKCS#11 portal

[yoe]

Similarly to the NativeMessaging issue in #655, it might be a good idea to have a PKCS#11 portal. This portal could just use p11-kit on the unconfined side, and then export all modules that are registered in p11-kit.

PKCS#11 is used by browsers and other applications to extend cryptography engines, e.g. to allow for authentication or cryptographic signatures with keys on smartcards, as used by many European countries for their ID cards (I work on supporting the Belgian eID software, of which the main part is a PKCS#11 module, but Estonia's infrastructure uses a similar method).

While the NativeMessaging portal would support a method currently used by browsers for out-of-process handling, a PKCS#11 portal would be used not only by browsers, but also by email clients (e.g., thunderbird and evolution support PKCS#11), office suites (libreoffice), and probably other applications too.

[frankmorgner]

Your idea has been demonstrated with shap in this project https://github.com/valentindavid/pkcs11-demo

[3v1n0]

@frankmorgner regarding this, it would be nice if we could discuss better an API to provide, however I was thinking that maybe we could handle this differently from how the message portal works, by avoiding exposing the modules at all to the confined apps, but instead exposing to the modules a generic smartcards without any direct contact with the p11-kit modules providing them.

I'm wondering if this would be possible, by usng your cool virtual smartcard to separate the actual modules (often closed source too) from both the system and the sandoboxed app.

So ideally:

• Multiple(?) sandoboxes that include the modules and provides them as plugins
• A snadboxed app that includes vpcd and exposes all the smartcards as vritual ones (reflecting the [hardware] ones provided by the modules)
• All the sandboxed apps that need smartcard access will connect to vpcd to access to all the available cards

A part handling the security concerns, this would also make it easier for the applications to use the smartcards, because they won't have to check what modules to load, but just one.

[frankmorgner]

It depends on what you want to do... vpcd/vicc are exposing the token itself. pkcs11-proxy is exposing the middleware that is making the token accessible:

┌──────────────┐                   ┌────────────┐                ┌──────────────┐
│              ├─────┐             │            ├────────┐       │              │
│  smart card  │PCSC │◄─────┬──────┤ pkcs#11    │ PKCS11 │◄───┬──┤   Firefox    │
│              ├─────┘      │      │ middleware ├────────┘    │  │              │
└─────┬────────┘            │      └──────┬─────┘             │  │   Thunderbird│
      │                     │             │                   │  │              │
      ▼                     │             ▼                   │  │   ssh        │
┌─────────────┐             │    ┌───────────────┐            │  │              │
│exposed by   ├──────┐      │    │ exposed by    ├───────┐    │  │   OpenSSL    │
│vicc/vpcd    │ PCSC │◄─────┘    │ pkcs11-proxy  │PKCS11 │◄───┘  │   P11-Engine │
└─────────────┴──────┘           │               ├───────┘       │              │
                                 └───────────────┘               └──────────────┘

Also, you may want to consider that PCSC-Lite has a similar functionality as vpcd with libpcsclite connecting to a remote instance of pcscd (that doesn't work cross platform, but it should be good enough for flatpack/snap/appimage.

What you want to seperate from each other, I think, is the user application (e.g. Firefox) from the middleware (e.g. the pkcs#11 implementation). For this use case you should use pkcs11-proxy. If you want to further seperate the middleware from the token's hardware driver (i.e. PC/SC driver), you could use vpcd/vicc.

There are only very few applications that want direct access to the hardware token itself (i.e. to PC/SC), for example pcsc-tools or yubico-piv-tool. For those, you could use the same separation as described above between middleware and token hardware.

[3v1n0]

I see, based on this it would be nice if we could try to define a portal API to be included in this repo.

[jmaris]

Just as a heads up: the European Union is in the process of adopting this as a standard for Digital Identity Documents (extending the existing eIDAS system). Support for this will likely become quite important for EU-based users.

[ueno]

FWIW I drafted a design of flatpak portal for PKCS#11 some time ago, which I'm attaching here. My concern on exposing all modules to flatpak is that a malicious application could brick smartcards by calling destructive functions like C_InitToken or by repeatedly providing incorrect PIN. Therefore the proposal is to dynamically forward certain tokens and escalate access privileges under user's consent.

[frankmorgner]

In general, I agree that sandboxed applications need permission in order to access resources beyond their sandboxed scope. I wonder if this is always the case if some basic I/O IPC is performed by some flatpack-sandboxed application (think of: accessing the Filesystem or accessing USB devices)...

Apple has started to enforce this a couple of years back as well and received a lot of anger for this. And I think it was in Windows Vista, where MS tried the same and rolled it back to a more relaxed style of permission checks in later releases...

[frankmorgner]

Does flatpack have a mechanism of signing packages? If so, you may want to consider whitelisting known friendly applications that do not misuse the exposed hardware by p11-proxy so that the user doesn't need to give consent manually. (This behavior could also be used for other I/O operations with different scopes well.)

[mcatanzaro]

The security model is to protect against compromised applications.

Applications that are intentionally malicious will just declare a sandbox hole in their manifests and bypass this.

[frankmorgner]

The security model is to protect against compromised applications.

Applications that are intentionally malicious will just declare a sandbox hole in their manifests and bypass this.

Do you want to imply that we don't need any protection against the misuse of a PKCS#11 token? That protection was implied by the drafted specification from @ueno. My suggestion above (signed flatpack applications) were meant as implementation suggestion to authorize a known (signed) friendly application with a known (signed) friendly manifest without manual user interaction. My suggestion would not cover unknown applications.

[Erick555]

All flatpak apps on flathub are signed which doesn't mean they aren't malicious. App can add malicious code minute after it was considered friendly (whatever friendly means to you).

In the proposed spec token access happens after user consent similarly to file access portals.

[frankmorgner]

One Question regarding the proposed architecture: It assumes that p11-kit-proxy is running directly in the host system (as well as the PKCS#11 module for accessing the smart card. Would it make sense to sandbox the module and/or the proxy as well? This was the approach from the snap demo above.

All flatpak apps on flathub are signed which doesn't mean they aren't malicious. App can add malicious code minute after it was considered friendly (whatever friendly means to you).

What I want, as user, is a trusted distribution channel, which gives me not-malicious applications that just work. What I learned is that flatpack is a trusted distribution channel, but the apps could be malicious. However, app developers could whitelist apps that are trusted and known to work. For example, a flatpack package from OpenSC running the pkcs11-kit-server could whitelist a Mozilla flatpack package running the pkcs11-kit-client for I/O. The burden of giving consent would shift from the user to the developer.

[ueno]

One Question regarding the proposed architecture: It assumes that p11-kit-proxy is running directly in the host system (as well as the PKCS#11 module for accessing the smart card. Would it make sense to sandbox the module and/or the proxy as well? This was the approach from the snap demo above.

As suggested on https://github.com/p11-glue/p11-kit/issues/294#issuecomment-622359664 that is possible through a remote: configuration option with bubblewrap, which flatpak internally uses. We have a plan to make it easy to setup, though I don't think it is in the scope of the portal proposal. Cc @ZoltanFridrich, who is actively working on p11-kit usability improvements these days.

[Erick555]

Flatpak unlike snap isn't packaging format for daemons and flatpak apps usually don't talk to each other.

What you expect is either flatpak app store being extremely closed garden where only world-wide-known developers and admin cronies could publish their apps or delusion where someone is able to vouch for random people and their code. Give me one example of app store available for everyone that you can trust.

[frankmorgner]

What you expect is either flatpak app store being extremely closed garden where only world-wide-known developers and admin cronies could publish their apps or delusion where someone is able to vouch for random people and their code.

My intent is to create a better user experience iff she is interested in some well known use case. If she wants to do something else, don't feel restricted to those and go ahead and ask her for consent. For PKCS#11 in particular, only a handful of applications are used in 80% of the cases.

[iavael]

@frankmorgner

However, app developers could whitelist apps that are trusted and known to work. For example, a flatpack package from OpenSC running the pkcs11-kit-server could whitelist a Mozilla flatpack package running the pkcs11-kit-client for I/O. The burden of giving consent would shift from the user to the developer.

So if I develop an pkcs11-compatible program for using it personally or at my job for internal use, then I have to reach opensc developers and ask them to whitelist my program? That sounds a bit extreme.

[frankmorgner]

If whitelisted, PKCS#11 access would be granted without user consent. If not whitelisted, the user would have to give consent.

But maybe my idea stems from a wrong understanding of the flatpack design and isn't really applicable.

[jadahl]

Listing "blessed" applications is not how portals are designed. Having to trust a moderated list of application authors is problematic in itself, and it also side steps one of the most important aspects of sandboxing - compromised apps, trusted or not.

[frankmorgner]

Again: I suggested an optional extension to avoid the user consent. Since you stated above that you're actively working on usability improvements, I thought this would be the right place to put such a suggestion.

[Mikenux]

As for the trusted devs part, this is not possible because flatpak devs and contributors should analyze the source code of the apps and check if each update contains problematic changes; this is also impossible to do for proprietary apps. They certainly don't have the resources for that; even flathub devs couldn't do it. I believe there have even been some review issues in the big companies (because their employees certainly can't always test/review everything properly). Additionally, any dev can host their own repository, which clearly won't be monitored by flatpak devs. The way the portals are made seems good to me (even if some improvements here and there can be made); they should be as objective as possible.

As for what you want, the only way for a user to avoid consenting is to consent to always grant access to the certificates. This is the information that we will give to the user to tell them whether an app is reliable enough or not, while handling the change of permission in case of an app update.

[jmpolom]

For example, a flatpack package from OpenSC running the pkcs11-kit-server could whitelist a Mozilla flatpack package running the pkcs11-kit-client for I/O. The burden of giving consent would shift from the user to the developer.

The idea that flatpaks would need to be "authorized" or "notarized" (as in the hideous system Apple requires on macOS) to prevent user annoyance is absurd. This idea needs to be fully ruled out. These notarization paradigms DO NOT meaningfully improve security posture and are basically just a useless bureaucratic layer that consolidates platform control at the top. These systems are user hostile by definition as they remove complete control over the system from the end user. If you want to alienate users from flatpak, start requiring packages to be signed by some official authority before they can be used.

If a user wants to run a questionable application, why should flatpak stop such a seemingly consensual, voluntary decision? Flatpak does not need to be a digital nanny. Defining what is or is not malicious is not a decision for a packaging system to make. What flatpak should provide though are some reliable, simple, user friendly controls the end user can employ to try and isolate applications from sensitive resources. The portal idea seems to embody this concept.

This portal could just use p11-kit on the unconfined side, and then export all modules that are registered in p11-kit.

This sounds like the most reasonable suggestion thus far in this issue. It is simple and straightforward to implement and also easy to understand+configure (no configuration needed maybe?) for users. I am concerned that the granular permissions model that is being discussed could become rather obnoxious for users if they're constantly being prompted via a modal dialog to allow an app to access a token or module (if a preference is saved, how is it later deleted or edited?). There's a potential here for even multiple prompts associated with a single token interaction because the sandboxed app is also likely to ask the user which token should be used. There's a likelihood this could lead to some kind of MFA prompt fatigue and the user resorts to just "allowing all always" to dispense with the annoyance.

I also don't see any actual reason for this level of control.

My concern on exposing all modules to flatpak is that a malicious application could brick smartcards by calling destructive functions like C_InitToken or by repeatedly providing incorrect PIN.

This seems like a rationale for having an abstraction and granular permissions model for accessing PKCS 11 tokens from the sandbox but I don't think it's fully water tight at this time. An application on the host itself could perform a similar denial of service attack on the card. And flatpak has zero control (nor should it) over what is going on at the host level via non-sandboxed applications. Flatpak should stick to controlling what it can and not worry about things outside of its control. Flatpak will not save the user from all possible maladies.

If a user is concerned that a particular application may be malicious and intend to access a token improperly, the best course of action for the user is to physically (if possible) or logically remove the token from the system. A rate limit on certain destructive calls might not be a bad idea but I disagree that an appropriate place for such a limit is in a high level sandbox API. The rate limit should be lower down in the stack, closer to where the hardware is interacted with (so maybe p11-kit, opensc or pcsc?). Not in this portal though, that is for certain I'd say.

Instead of a granular permissions model where perhaps every token transaction is subject to a permission, I advocate for something coarser where the user can simply allow a given flatpak access to PKCS 11 modules. I don't think it needs to be any more granular than that. Similar to granting access to the pcsc socket at the package level or via flatpak run CLI flags. Simple is best here.

I am quite concerned reading through this issue that there is a tendency to over complicate and over engineer what is needed here. I do not think that unabated this approach will lead to a reliable solution or a good user experience.