Stef <stef-list memberwebs com> writes: > 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. Yes, you're absolutely right. > 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. OK. I agree and would like to move forward with designing such a system. I don't think we will get around the fact that the supplicant may be running as a different user, not necessarily root, but that's not to say the supplicant can not somehow be granted the necessary access to the keyring. If we were talking about a generic capability system, I would want to say that NM would propose to the user that she allow the supplicant to access her keyring, and in response to the user's response, NM would issue a capability to the keyring on the user's behalf which would be sent to the supplicant over DBus and then passed into the keyring's cryptoki module's init args. This is similar to what I was proposing with the auth parameter. Code could be added to wpasupplicant to make it SELinux aware and allow it to switch roles based on DBus messages, and then it would be an issue of system policy to determine if the desktop user is allowed to manipulate the state of the supplicant. The next most logical option is redesigning wpasupplicant so that all cryptographic operations would run in the user's context. I believe this would be much harder than making wpasupplicant SELinux aware, if indeed that is necessary. Is there anyone who can advise us on these issues? (*nudge to Dan* possibly at RedHat?) - dds
Attachment:
pgpoLovxVEOgT.pgp
Description: PGP signature