NetworkManager & PKCS#11 remoting

[Nikos Mavrogiannopoulos]

On Wed, 2016-06-22 at 11:26 +0100, David Woodhouse wrote:
> On Wed, 2016-06-22 at 11:53 +0200, Nikos Mavrogiannopoulos wrote:
> > 
> > 
> > On second view we may not need any gnutls changes for module-path.
> > If
> > that module is already initialized (e.g., already registered via
> > p11-
> > kit), then only p11_kit_uri_match_module_info() need to consider
> > that
> > information.
> That isn't the interesting use case for module-path. The use case we
> were discussing here would be to load p11-kit-remote.so when it
> *wouldn't* otherwise have been loaded.
> And we really do want it to be explicitly requested by module-path or
> some other means, rather than *only* by an environment variable that
> anyone can set before invoking a program. I'd be *really* wary of
> that.

Correct, we need module-path explicit support to load any additional
modules not already loaded.

But still we would require some kind of registration of these modules
via p11-kit, or pkcs11 URLs will not be usable from from privileged
processes if they are acquired from an unprivileged one.

> > For remote-fd, it would require changes to every application using
> > p11-
> > kit (engine_pkcs11, etc). I don't see how it could work without
> > hard-
> > coding it to every application.
> Not application, surely? Only in GnuTLS, engine_pkcs11 and NSS. And
> the
> latter doesn't have *any* modern PKCS#11 URI support or p11-kit
> integration anyway; right now the best advice for distribution
> packages
> is "Do Not Build Against NSS". But we *can* fix them all.

We could, but the error surface is quite large. I don't believe we can
sufficiently expect to add such a code path in three+ libraries and
expect it to work the same way everywhere. The solution with getenv()
requires support only in the newly introduced module thus I find it
much cleaner.

regards,
Nikos