Re: GGF's extensions to GSS in Public Comment

On Fri, Apr 02, 2004 at 08:30:29AM -0600, Von Welch wrote:
> Nicolas,
> 
>  I haven't been privy to any of the hallway conversations you mention
> or known that they have existed. My impression from scanning the
> mailling lists has been that your draft was basically uncommented on,
> so I mistook this for a lack of interest.

An unfortunate case of miscommunication.  I will write separately about
how to avoid this in the future, after I think about this some more.

>  I'll respond here to your critique of our use of environmental
> variables in gss_export_cred() from your ID[1]. Perhaps you can give me
> pointers to the other critiques from you and Sam that you refer to. I
> don't remember these and am not having any luck with google.

Sam, myself, (and others?) have posted our critiques on the KRB WG list,
and, maybe, on the old CAT WG list, in response to Doug's posts
referring to the GGF's proposal or updates thereto.

You may want to search the KRB and CAT WG mailing list archives[1].

>  In regards to your comment regarding our exposure of environmental
> variables in our gss_export_cred() call: The reason why we chose this
> route is that we've had bad experiences with functions that manipulate
> the environment without providing knowledge of that manipulation to
> their calling applications. Doing this leads to the problem that if
> that an application wants to clean up its environment, typically in
> preparation for passing just the needed subset to a child, it has no
> way of knowing that a particular environment variable is meaningful as
> a pointer to a credential (unless it assumes knowledge of the
> underlying GSS mechanism and its use of the environment, which is what
> most apps seem to do).

I answer this below.  BTW, I have implementation experience with my
proposal.

>  As I understand your proposal to avoid environmental variables in
> gss_store_cred(), it seems implicit that when storing credentials in
> some location other than the default (i.e. default_cred == FALSE) some
> mechanism-specific environment variable would need to be set by the
> underlying mechanism (at least for the implementations of GSSAPI I'm
> familar with) to allow the credential to be found at later time,
> leading to the problem I mention above.

You've misunderstood the proposal.  The default_cred parameter is NOT
about the default credential _store_: it's about the default
_credential_, that which would be acquired if using GSS_C_NO_NAME, the
GSS_C_NO_CREDENTIAL.

Do not confuse "default credential store" and "default credential" --
these are two very different concepts.

The issue for both proposals is about addressing a credential store.  I
deliberately chose to leave that as a platform-specific matter, though I
gave some examples of how credential stores would be manipulated on some
platforms.  More below.  Please bear with me.

>  Using only the default credential store is fine if a user only has
> one set of credentials on a given system, but if a user has, for
> example, multiple sessions with a different delegated credential for
> each (so that each delegated credential can be removed on closure of
> its associated session) this breaks down as there is no way
> store_cred() can store a credential in a location other than default
> location and pass it through an exec() call that I can tell.

Again, you've misunderstood the proposal.  The following may be long,
but please bear with me.

GSS_Store_cred() stores credentials into whatever is the caller's
"current" credential store.  The matter of how to manipulate one's
"current" credential store is a platform-specific matter.

On Windows, for example, the current credential store might be tied to
user impersonation tokens.

On Solaris, where only a single credential store per-user is supported
(well, for use with Secure NFS anyways) the current credential store is
tied to the EUID of the caller.

On *nix platforms with PAM support the current credential store might be
settable like so:

extern char **environ;

static uid_t saved_euid = (uid_t)-1;
static char **saved_environ = NULL;
int
set_gss_cred_store(pam_handle_t pamh, struct passwd *pw)
{
	int retval;

	if ((retval = pam_setcred(pamh, PAM_ESTABLISH_CRED)) != PAM_SUCCESS)
		return 0;
	saved_environ = environ;
	environ = pam_getenvlist(pamh);

	saved_euid = geteuid();
	if (seteuid(pw->pw_uid) < 0) {
		environ = saved_environ;
		saved_environ = NULL;
		saved_euid = (uid_t)-1;
		return 0;
	}

	return 1;
}

int
revert_gss_cred_store(pam_handle_t pamh)
{
	char **tmp_env, **p;

	if (uid_t == (uid_t)-1)
		return 0;
		
	tmp_env = environ;
	environ = saved_environ;

	/* Free PAM env */
	for (p = tmp_env ; p != NULL && *p != NULL ; p++) {
		free(*p);
	}
	if (tmp_env != NULL)
		free(tmp_env);

	if (seteuid(saved_euid) < 0) 
		return 0;

	return 1;
}

Solaris 10 won't require this in that it only supports one credential
store per-user (again, for Secure NFS anyways), but this will be
perfectly ok to do on Solaris 10.


This can actually be abstracted more, and I have an Internet-Draft
waiting in the wings that provides for a very basic credential store
manipulation API that consists of:

 - GSS_Get_current_cred_store() ->
	Get a handle to current cred store.  There are no store "names"
	-- just handles.


 - GSS_Set_current_cred_store() ->
	Set a current cred store; creates a new cred store if the given
	store handle is GSS_C_NULL_CRED_STORE.  There are no store
	"names" -- just handles.

	This function cannot and does not change the user context of the
	caller; that remains the caller's responsibility.


 - GSS_Inquire_mechs_for_cred_context() ->
	List the mechs which the current store supports.


I hope it's clear now that gss_store_cred() does succeed in keeping
platform-specific details (e.g., environment variables) out of the spec,
and that it does so by punting (with some recommendations and examples)
on the matter of how to manipulate one's current credential store.

At the risk of repeating too much of the I-D's content here I'll remind
you that GSS_Acquire/Add_cred(), and all GSS-API functions that can use
GSS_C_NO_CREDENTIAL, implicitly assume that there is a credential store
in the background to acquire credentials from.  Merely adding a
GSS_Store_cred() patterned on GSS_Acquire/Add_cred(), and relaying on
the notion of an implicit credential store does not require that we add
an abstraction for manipulating one's credential store anymore than
having GSS_Acquire/Add_cred() did in the first place.

Cheers,

Nico
-- 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]