Dan Williams <dcbw redhat com> writes: > On Fri, 2008-07-25 at 23:45 +0000, Stef wrote: >> Dan Williams wrote: >> > I think the real fix for this is to get Gnome Keyring using D-Bus, not >> > sockets. That needs to be done anyway. This sort of call in the >> > supplicant seems really ugly to me. >> >> Gnome Keyring supports a variety of standards and access methods for >> various things. It sits as a bridge between a bunch of technologies, >> some ancient and some modern. >> >> In this case wpasupplicant accessing gnome-keyring PKCS#11 via which >> is a standardized API for public key access and crypto operations. This >> API is provided by a module. >> >> Internally a socket it used to connect from the module to the >> gnome-keyring daemon. Why isn't Dbus used for this connection? We tried >> hard to make that work, but in the end: > > In the end you need a well-known name for how to connect to the keyring. > The advantage with D-Bus is that you do have a well-known name to > connect to. The disadvantage of the current system is that every app > that wants to use Gnome Keyring needs to know the random gnome keyring > socket path via environment variables, which is a total fail for exactly > the reason presented in this case. > >> * DBus has a rigid locking and threading model is incompatible with >> the threading model of PKCS#11 modules. >> * DBus provides no credentials information on who the other side of the >> caller is. > > What kind of credentials are needed here? You'll get at least the uid > of the caller via SO_PEERCRED. Any other credentials need would be > passed inside the D-Bus message just like they are probably passed > around inside PKCS11 somewhere. > >> This just isn't what DBus is designed for. This was discussed on the >> DBus mailing list. >> >> http://lists.freedesktop.org/archives/dbus/2007-April/007454.html >> http://lists.freedesktop.org/archives/dbus/2007-April/007458.html >> >> On the other hand, certain parts of gnome-keyring are exposed via DBus. >> And you can get the appropriate socket path for the current user >> session, via DBus. > > Good! That should solve this issue then. The only reason to pass > random environment variables through the supplicant was to set the > keyring path IIRC. It should be pretty easy to get that path inside the > supplicant's PCKS11 code without having to resort to having the user > agent push down the environment variable array. We may need to invent > another command to tell the supplicant about the user we're requesting > credentials for of course. No, we should not need to invent another command to tell the supplicant about the user we're requesting credentials for. Cryptoki does not care about users and we should impose on cryptoki implementations that could be used with supplicants via NM. But, gnome-keyring as a cryptoki provider is special in that it cares about the user it is operating on behalf of. Since the plan is already to have NM (or another cryptoki agent) get the gnome-keyring socket over DBus and pass that to the supplicant for its initialization args to the cryptoki module, could gnome-keyring also provide an API to get a hashed nonce that would also be used in the cryptoki init args in order to authorize the access on behalf of the user who retrieved the nonce? So, the init args to gnome-keyring's cryptoki implementation would look like "socketpath=/path/to/keyring.sock&auth=<HASHED_NONCE>" - dds
Attachment:
pgpORKFjkgJ2j.pgp
Description: PGP signature