putty/unix/uxgss.c

176 строки
4.8 KiB
C
Исходник Обычный вид История

#include "putty.h"
#ifndef NO_GSSAPI
#include "pgssapi.h"
#include "sshgss.h"
#include "sshgssc.h"
/* Unix code to set up the GSSAPI library list. */
#if !defined NO_LIBDL && !defined NO_GSSAPI
const int ngsslibs = 4;
const char *const gsslibnames[4] = {
"libgssapi (Heimdal)",
"libgssapi_krb5 (MIT Kerberos)",
"libgss (Sun)",
"User-specified GSSAPI library",
};
const struct keyvalwhere gsslibkeywords[] = {
{ "libgssapi", 0, -1, -1 },
{ "libgssapi_krb5", 1, -1, -1 },
{ "libgss", 2, -1, -1 },
{ "custom", 3, -1, -1 },
};
/*
* Run-time binding against a choice of GSSAPI implementations. We
* try loading several libraries, and produce an entry in
* ssh_gss_libraries[] for each one.
*/
static void gss_init(struct ssh_gss_library *lib, void *dlhandle,
int id, const char *msg)
{
lib->id = id;
lib->gsslogmsg = msg;
lib->handle = dlhandle;
#define BIND_GSS_FN(name) \
lib->u.gssapi.name = (t_gss_##name) dlsym(dlhandle, "gss_" #name)
BIND_GSS_FN(delete_sec_context);
BIND_GSS_FN(display_status);
BIND_GSS_FN(get_mic);
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 09:18:59 +03:00
BIND_GSS_FN(verify_mic);
BIND_GSS_FN(import_name);
BIND_GSS_FN(init_sec_context);
BIND_GSS_FN(release_buffer);
BIND_GSS_FN(release_cred);
BIND_GSS_FN(release_name);
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 09:18:59 +03:00
BIND_GSS_FN(acquire_cred);
BIND_GSS_FN(inquire_cred_by_mech);
#undef BIND_GSS_FN
ssh_gssapi_bind_fns(lib);
}
/* Dynamically load gssapi libs. */
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 22:52:21 +04:00
struct ssh_gss_liblist *ssh_gss_setup(Conf *conf)
{
void *gsslib;
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 22:52:21 +04:00
char *gsspath;
struct ssh_gss_liblist *list = snew(struct ssh_gss_liblist);
list->libraries = snewn(4, struct ssh_gss_library);
list->nlibraries = 0;
/* Heimdal's GSSAPI Library */
if ((gsslib = dlopen("libgssapi.so.2", RTLD_LAZY)) != NULL)
gss_init(&list->libraries[list->nlibraries++], gsslib,
0, "Using GSSAPI from libgssapi.so.2");
/* MIT Kerberos's GSSAPI Library */
if ((gsslib = dlopen("libgssapi_krb5.so.2", RTLD_LAZY)) != NULL)
gss_init(&list->libraries[list->nlibraries++], gsslib,
1, "Using GSSAPI from libgssapi_krb5.so.2");
/* Sun's GSSAPI Library */
if ((gsslib = dlopen("libgss.so.1", RTLD_LAZY)) != NULL)
gss_init(&list->libraries[list->nlibraries++], gsslib,
2, "Using GSSAPI from libgss.so.1");
/* User-specified GSSAPI library */
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 22:52:21 +04:00
gsspath = conf_get_filename(conf, CONF_ssh_gss_custom)->path;
if (*gsspath && (gsslib = dlopen(gsspath, RTLD_LAZY)) != NULL)
gss_init(&list->libraries[list->nlibraries++], gsslib,
3, dupprintf("Using GSSAPI from user-specified"
" library '%s'", gsspath));
return list;
}
void ssh_gss_cleanup(struct ssh_gss_liblist *list)
{
int i;
/*
* dlopen and dlclose are defined to employ reference counting
* in the case where the same library is repeatedly dlopened, so
* even in a multiple-sessions-per-process context it's safe to
* naively dlclose everything here without worrying about
* destroying it under the feet of another SSH instance still
* using it.
*/
for (i = 0; i < list->nlibraries; i++) {
dlclose(list->libraries[i].handle);
if (list->libraries[i].id == 3) {
/* The 'custom' id involves a dynamically allocated message.
* Note that we must cast away the 'const' to free it. */
sfree((char *)list->libraries[i].gsslogmsg);
}
}
sfree(list->libraries);
sfree(list);
}
#elif !defined NO_GSSAPI
const int ngsslibs = 1;
const char *const gsslibnames[1] = {
"static",
};
const struct keyvalwhere gsslibkeywords[] = {
{ "static", 0, -1, -1 },
};
/*
* Link-time binding against GSSAPI. Here we just construct a single
* library structure containing pointers to the functions we linked
* against.
*/
#include <gssapi/gssapi.h>
/* Dynamically load gssapi libs. */
Post-release destabilisation! Completely remove the struct type 'Config' in putty.h, which stores all PuTTY's settings and includes an arbitrary length limit on every single one of those settings which is stored in string form. In place of it is 'Conf', an opaque data type everywhere outside the new file conf.c, which stores a list of (key, value) pairs in which every key contains an integer identifying a configuration setting, and for some of those integers the key also contains extra parts (so that, for instance, CONF_environmt is a string-to-string mapping). Everywhere that a Config was previously used, a Conf is now; everywhere there was a Config structure copy, conf_copy() is called; every lookup, adjustment, load and save operation on a Config has been rewritten; and there's a mechanism for serialising a Conf into a binary blob and back for use with Duplicate Session. User-visible effects of this change _should_ be minimal, though I don't doubt I've introduced one or two bugs here and there which will eventually be found. The _intended_ visible effects of this change are that all arbitrary limits on configuration strings and lists (e.g. limit on number of port forwardings) should now disappear; that list boxes in the configuration will now be displayed in a sorted order rather than the arbitrary order in which they were added to the list (since the underlying data structure is now a sorted tree234 rather than an ad-hoc comma-separated string); and one more specific change, which is that local and dynamic port forwardings on the same port number are now mutually exclusive in the configuration (putting 'D' in the key rather than the value was a mistake in the first place). One other reorganisation as a result of this is that I've moved all the dialog.c standard handlers (dlg_stdeditbox_handler and friends) out into config.c, because I can't really justify calling them generic any more. When they took a pointer to an arbitrary structure type and the offset of a field within that structure, they were independent of whether that structure was a Config or something completely different, but now they really do expect to talk to a Conf, which can _only_ be used for PuTTY configuration, so I've renamed them all things like conf_editbox_handler and moved them out of the nominally independent dialog-box management module into the PuTTY-specific config.c. [originally from svn r9214]
2011-07-14 22:52:21 +04:00
struct ssh_gss_liblist *ssh_gss_setup(Conf *conf)
{
struct ssh_gss_liblist *list = snew(struct ssh_gss_liblist);
list->libraries = snew(struct ssh_gss_library);
list->nlibraries = 1;
list->libraries[0].gsslogmsg = "Using statically linked GSSAPI";
#define BIND_GSS_FN(name) \
list->libraries[0].u.gssapi.name = (t_gss_##name) gss_##name
BIND_GSS_FN(delete_sec_context);
BIND_GSS_FN(display_status);
BIND_GSS_FN(get_mic);
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 09:18:59 +03:00
BIND_GSS_FN(verify_mic);
BIND_GSS_FN(import_name);
BIND_GSS_FN(init_sec_context);
BIND_GSS_FN(release_buffer);
BIND_GSS_FN(release_cred);
BIND_GSS_FN(release_name);
Support GSS key exchange, for Kerberos 5 only. This is a heavily edited (by me) version of a patch originally due to Nico Williams and Viktor Dukhovni. Their comments: * Don't delegate credentials when rekeying unless there's a new TGT or the old service ticket is nearly expired. * Check for the above conditions more frequently (every two minutes by default) and rekey when we would delegate credentials. * Do not rekey with very short service ticket lifetimes; some GSSAPI libraries may lose the race to use an almost expired ticket. Adjust the timing of rekey checks to try to avoid this possibility. My further comments: The most interesting thing about this patch to me is that the use of GSS key exchange causes a switch over to a completely different model of what host keys are for. This comes from RFC 4462 section 2.1: the basic idea is that when your session is mostly bidirectionally authenticated by the GSSAPI exchanges happening in initial kex and every rekey, host keys become more or less vestigial, and their remaining purpose is to allow a rekey to happen if the requirements of the SSH protocol demand it at an awkward moment when the GSS credentials are not currently available (e.g. timed out and haven't been renewed yet). As such, there's no need for host keys to be _permanent_ or to be a reliable identifier of a particular host, and RFC 4462 allows for the possibility that they might be purely transient and only for this kind of emergency fallback purpose. Therefore, once PuTTY has done a GSS key exchange, it disconnects itself completely from the permanent host key cache functions in storage.h, and instead switches to a _transient_ host key cache stored in memory with the lifetime of just that SSH session. That cache is populated with keys received from the server as a side effect of GSS kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if later in the session we have to fall back to a non-GSS key exchange. However, in practice servers we've tested against do not send a host key in that way, so we also have a fallback method of populating the transient cache by triggering an immediate non-GSS rekey straight after userauth (reusing the code path we also use to turn on OpenSSH delayed encryption without the race condition).
2018-04-26 09:18:59 +03:00
BIND_GSS_FN(acquire_cred);
BIND_GSS_FN(inquire_cred_by_mech);
#undef BIND_GSS_FN
ssh_gssapi_bind_fns(&list->libraries[0]);
return list;
}
void ssh_gss_cleanup(struct ssh_gss_liblist *list)
{
sfree(list->libraries);
sfree(list);
}
#endif /* NO_LIBDL */
#endif /* NO_GSSAPI */