setEnvironmentVariable DBus method for wpasupplicant

[Stef]

David Smith wrote:
> 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>"

Stepping this far across user and security boundaries will cause
problems. Not only with gnome-keyring as it currently is, but it'll
certainly cause problems with selinux, apparmor and other stuff.

I'm not currently intimately familiar with these security systems.
However we've already experienced this with gdm process trying to access
gnome-keyring in the PAM module on selinux enabled systems like Fedora
[1]. Also at some point in the future we'll be integrating tighter linux
MAC security into gnome-keyring.

I would recommend that some part of the user's session (credentials,
security context) interact with gnome-keyring rather than a root process
somewhere on the computer. I know this may make things a bit more
complicated, but in the long run it would cause far less problems.

Cheers,

Stef Walter

[1] http://bugzilla.gnome.org/show_bug.cgi?id=484612