NetworkManager & PKCS#11 remoting

David Woodhouse dwmw2 at infradead.org
Tue Jun 21 11:35:08 UTC 2016


On Mon, 2016-06-20 at 15:50 +0200, Lubomir Rintel wrote:
> The overall design & the prototype is described here; I'm wondering if
> it looks sane to you? https://bugzilla.gnome.org/show_bug.cgi?id=767872

Nikos and I had a brief chat on IRC since I suspected we were talking
past each other a little bit.

Generally, we discourage the use of module paths and loading specific
modules. Let's not go there — the remote provider which runs as the
individual user can just load the *standard* set of PKCS#11 modules
according to the p11-kit config. It's basically as if you have
'p11-kit-proxy.so' as the module to be proxied. The consumer side (NM)
can't know which module provides 'pkcs11:object=My%20VPN%20Key' today
*anyway*. So it *can't* ask for a specific module to be loaded.

The patches which extend the remoting protocol to support running over
an existing FD seem entirely sensible, as a mechanism.

The existing way of *using* them, with a P11_REMOTE_FD environment
variable that anyone can set before invoking an application, we assume
is a straw man — obviously we need to work out the *right* way to do
that.

We talked about a separate p11-kit-remote.so module. For *that* to
depend on an environment variable would be saner — it wouldn't allow
users to just set that variable and then observe *strange* behaviour in
anything they invoke (which might not know to clear that variable and
treat it as secure).

For wpa_supplicant and openvpn at least it's sometimes possible to
configure them explicitly to use a given provider module, instead of
p11-kit-proxy.so which is their default. But there are other cases
(including wpa_supplicant when built against GnuTLS) where that doesn't
work. It wouldn't work for OpenConnect either, although OpenConnect is
largely irrelevant here because it needs its certs in the auth-dialog
which does run in the user's session anyway. (But hey, maybe it needs
access to *root's* certs?)

So maybe we do actually want to fix p11-kit to allow a module-path to
be specified in a URI, and then NM would invoke wpa_supplicant /
openvpn / etc with a URI containing 'module-path=p11-kit-remote.so'.

Or (and I thought of this as writing up, so we've moved on from the bit
I discussed with Nikos and was trying to summarise) perhaps we could
use a vendor-specific attribute like 'v-remote-fd=5' in the URI.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/p11-glue/attachments/20160621/f589d510/attachment.bin>


More information about the p11-glue mailing list