NetworkManager & PKCS#11 remoting

Nikos Mavrogiannopoulos nmav at redhat.com
Wed Jun 22 16:25:26 UTC 2016


On Wed, 2016-06-22 at 13:16 +0000, David Woodhouse wrote:
> > 
> > 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.

> Hm, I think you're conflating the "what module does wpa_supplicant
> itself
> load?" question (A: p11-kit-remote.so), with the "what modules are
> visible
> to/through the stub running in the user session?" question (A: the
> standard configured set).

I'm not sure I follow.

> > 
> > 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.
> So you want p11-kit-remote to be in the default set for root (for
> certain
> apps?) and normally it'll fail to initialise unless the variable is
> set?
> Talk me through the security implications of that. I concede it only
> scares me; I have no specific attack model in mind. Let's assume we
> *don't* allow trusted certs through the remote, or you fail to
> convince me
> before you even start... :)

That's not what I said. What I said is that I don't like a solution
which requires to change 3 other libs in order for it to work reliably
and I prefer one which is contained to the module in question. Whether
the module in question will be loaded by root by default or no is a
separate question which I didn't touch.

regards,
Nikos



More information about the p11-glue mailing list