Add pkcs11 interface to keyd in azure-iot-identity snap

[damonbarry]

Users of the azure-iot-identity snap package report that they are unable to use PKCS#11 functionality in keyd unless they install the snap with --devmode. This is because the snap does not have the pkcs11 interface connected. This change adds the interface.

[arsing]

Does it actually work? How? The tpm interface straightforwardly makes /dev/tpm{rm}0 available in the sandbox. But I can't figure out from the code what this one does, the docs are empty, and the only info I can find via web search for PKCS#11 in snap is that it does not work for Firefox users trying to use their smart cards.

[damonbarry]

Does it actually work? How? The tpm interface straightforwardly makes /dev/tpm{rm}0 available in the sandbox. But I can't figure out from the code what this one does, the docs are empty, and the only info I can find via web search for PKCS#11 in snap is that it does not work for Firefox users trying to use their smart cards.

Not sure. Because it's a privileged interface, you have to get permission from the snap store to connect it, so I don't think there's a way to test until the request to the store has been approved. As far as I can tell, it's a chicken-and-egg problem.

The implementation of the pkcs11 interface is here, is there anything you can derive from that?

[arsing]

Yes, that's the code that I said I couldn't figure out. Especially since it seems to be talking about a Unix socket for some reason. Maybe the idea is that the application doesn't use a PKCS#11 library directly but links to some snap-provided library that thunks through the sandbox to the real library running on the host or something. But given that it doesn't work for Firefox there must be more to it.

If it's something like it requires changes in the application, like the application has to make network calls to that socket instead of using a PKCS#11 library in the standard way, then it's not going to work.

[damonbarry]

If it's something like it requires changes in the application, like the application has to make network calls to that socket instead of using a PKCS#11 library in the standard way, then it's not going to work.

Makes sense. I'll need to dig into this some more.

[damonbarry]

@arsing did you notice the error in the rhel9 packages build? I didn't investigate deeply but it looks like maybe rhel9 upgraded from openssl 3.0 to 3.2 and that breaks our Makefile?

[arsing]

Yeah, but openssl version -e will still work for it. You can just relax the check to 'OpenSSL 3.'*.

[arsing]

Actually, you might as well get rid of that check entirely and uncondtionally call openssl version -e. This is leftover from when we supported 1.0 too for which the command didn't work. ef2d8c2#diff-76ed074a9305c04054cdebb9e9aad2d818052b07091de1f20cad0bbac34ffb52R282-R286

[damonbarry]

Following up on earlier concerns (above), @arsing commented on an internal thread:

Okay, I see. So the pkcs11 plug acts like p11-kit server, ie it loads the real PKCS#11 library and listens for requests on a Unix socket. Inside the sandbox the customer is presumably using p11-kit-client.so. That exposes a PKCS#11 interface in the standard way and implements it by forwarding requests over the unix socket to the server.

So yes it sounds like it'll work.

[damonbarry]

Snapcaft approved us publishing with the pkcs11 plug (see https://forum.snapcraft.io/t/request-to-publish-snap-with-pkcs11-plug/43976), and we've confirmed it works (user is able to install our snap without the --devmode option and use PKCS #11-related features).