NetworkManager & PKCS#11 remoting
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
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...
Size: 5760 bytes
Desc: not available
More information about the p11-glue