Document how to configure access to host PKCS#11 devices

[jmpolom]

It is not trivial to enable apps like web browsers to access host PKCS#11 devices nor do the steps appear documented anywhere. A process using a p11-kit-server user service and manual filesystem override should be officially documented. Several users responded indicating they were unaware how to configure this before seeing a buried comment on a PR. See: #5423 (comment)

[mcatanzaro]

Hi, currently to use host PKCS #11 devices you need to use sandbox holes. That's not good and not something that really belongs in the documentaiton. It's better for users to treat PKCS #11 as a future feature instead. The correct solution is to create a portal, which would then be documented by xdg-desktop-portal and wouldn't require manual user configuration.

[jmpolom]

Hi, currently to use host PKCS #11 devices you need to use sandbox holes. That's not good and not something that really belongs in the documentaiton. It's better for users to treat PKCS #11 as a future feature instead. The correct solution is to create a portal, which would then be documented by xdg-desktop-portal and wouldn't require manual user configuration.

Unfortunately PKCS#11 functionality is needed today in many applications but the portal you're alluding to does not exist today. It is unclear when or if it will ever exist. Many of the surrounding issues appear have been dormant for a year.

I agree long term some kind of fancy complicated portal might be a slick feature but again, users need working PKCS#11 devices inside flatpak apps today. There will always be a trade off between security and expediency but there's no harm in Flatpak providing users information to make their own decision with. Again the user stays completely in control over what apps can access the host PKCS#11 devices using the workaround. By configuring the host side p11-kit-server they could achieve even more control. I see no major security issues here whatsoever.

What is a major problem though is non-functionality of a needed feature. This is really bad. This is when users make worse workarounds because they need something to work that should work and they need it working yesterday. Here the worse workaround is to install the application on the host OS itself. This will have no sandboxing at all from the host. Certainly worse security-wise and also obnoxious to configure.

I created a gist with suggested steps that should be added to the documentation to help users get this working.

[mcatanzaro]

Really strongly recommend against documenting step 3 as that's not acceptable to present to users.

The correct solution here requires work unfortunately. So far nobody has cared enough to make it happen....

[jmpolom]

Really strongly recommend against documenting step 3 as that's not acceptable to present to users.

Why is that supported functionality if you deem it inappropriate? I find it completely acceptable and necessary functionality!

[swick]

It is unclear when or if it will ever exist

It will exist when someone starts to work on it. Constantly complaining on an issue achieves nothing.

[jmpolom]

Can someone else from Red Hat review this issue? These responses are unreasonable. This is a legitimate deficiency in flatpak and the solution being proposed is non-existent with no ETA. You're also refusing to document what is the present day workaround leaving users with only an option to "use something else" (pkcs#11 works fine on non-flatpak apps, and of course mac and windows).