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 _______________________________________________ p11-glue mailing list p11-glue@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/p11-glue
