setEnvironmentVariable DBus method for wpasupplicant

[Dan Williams]

On Mon, 2008-07-28 at 15:56 +0900, David Smith wrote:
> Stef <stef-list at 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.

This direction was suggested to people who know (Nalin D. I think?)
Basically, since the necessary credentials may be user-specific, and
since you don't want to hand secrets off all over the system, the
operations that require those secrets (initial TLS handshakes, session
key derivation, etc) should be done as close to the secret storage as
possible.  That could mean doing these operations in the user session as
the user's UID rather than as root.

However, the supplicant does need to be able to poke wireless stuff that
requires root privs, so there may need to be privilege separation or
something like that within the supplicant like you suggest.  But you
don't need to do _all_ crypto in the user session, you only need to run
the bits that derive the TLS session key (and rekeys perhaps) since
those are the only bits that really require the user secrets directly.

The alternative is to have a system-wide secret store and require all
users to stuff their certs/keys/passwords in the system wide store, and
then somehow ACL that system secret store.  But the reason we don't do
that already is that you need the secrets to follow you over network
logins and such, thus they are stored in your homedir, and to be able to
confine processes securely, you don't want random programs accessing
your homedir.

dan

> Is there anyone who can advise us on these issues? (*nudge to Dan*
> possibly at RedHat?)
> 
> - dds