* NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server @ 2012-03-12 20:02 Michael Weiser 2012-03-12 20:24 ` Jim Rees 2012-03-12 21:10 ` Kevin Coffman 0 siblings, 2 replies; 17+ messages in thread From: Michael Weiser @ 2012-03-12 20:02 UTC (permalink / raw) To: linux-nfs [-- Attachment #1: Type: text/plain, Size: 3713 bytes --] Hi, from what I can gather, nfs-utils-1.2.3 introduced support for encryption other than Single DES for NFSv4: Previously, gssd would proactively limit Kerberos encryption types of session keys to des-cbc-crc (and perhaps -md5 and -md4). So while the actual ticket might be encrypted using something way stronger, the included session key would only be Single DES. Due to this self-limitation of the client, the server would never get anything else than Single DES session keys and therefore needed no mechanism of working around the problems caused by stronger session keys with a kernel that does not support them. Beginning with version 1.2.3 of nfs-utils, gssd does no longer limits itself to Single DES. Instead, it detects the encryption types supported by the *client's* kernel and limits the session key's encryption type to those reported as supported. This, however, ignores the fact, that the *server's* kernel might not support them. Since the userspace of the server (svcgssd) does not check what its kernel supports and has no mechanism of renegotiating with the client, it happily accepts stronger encryption types and tries to push them into the kernel. nfs-utils-1.2.4 includes a patch to svcgssd that uses /proc/fs/nfsd/supported_encryption_types of newer kernels (2.6.35+ ?) to determine the encryption types supported by the server's kernel and uses subkey negotiation of current MIT Kerberos versions (1.9.1+) to negotiate a possibly weaker encryption type with the client. While this is a good solution for future enhancements and backwards compatibility from now on it still leaves all the older installations with a problem. RHEL5 for example only has MIT Kerberos 1.6 and will therefore most likely never benefit from this fix. A direct workaround is to set the following options in /etc/krb5.conf of client and server: [libdefaults] default_tkt_enctypes = des-cbc-md5 permitted_enctypes = des-cbc-md5 , add des-cbc-md5 keys to the keytabs of both machines and allow Single DES for both machines' principals on the KDC (MS AD 2008r2 in particular wants it enabled explicitly). This however not only limits the encryption types of session keys but all tickets as well and applies to the whole machine not just the NFSv4 service. This has a needlessly high security impact on both machines. I quickly implemented a more self-contained fix that adds an option -l to rpc.gssd that effectively reverts it to legacy behaviour: It ignores its local kernel's capabilities and uses just Single DES. This option could be set in e.g. /etc/sysconfig/nfs:GSSDARGS on all RHEL6 clients that need to work with RHEL5 servers. It could possibly be enhanced to be configurable on a per-machine basis. Inclusion of this or a similar patch would be greatly appreciated. Obviously this is just a proof-of-concept and still needs some polishing. I was just wondering if my reasoning is sound and the solution acceptable. Thanks in advance, -- Michael Weiser science + computing ag Senior Systems Engineer Geschaeftsstelle Duesseldorf Martinstrasse 47-55, Haus A phone: +49 211 302 708 32 D-40223 Duesseldorf fax: +49 211 302 708 50 www.science-computing.de -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 [-- Attachment #2: 0001-Add-l-option-to-gssd-to-force-legacy-behaviour.patch --] [-- Type: text/x-diff, Size: 2723 bytes --] >From bd051cd3cc50d8d4695693c8f2d8cf78935c5711 Mon Sep 17 00:00:00 2001 From: Michael Weiser <weiser@science-computing.de> Date: Mon, 12 Mar 2012 20:43:36 +0100 Subject: [PATCH] Add -l option to gssd to force legacy behaviour A new option -l forces gssd to ignore its kernel's crypto capabilities and use just the Single DES legacy encryption types to be compatible with old servers without re-negotiation functionality. --- utils/gssd/gssd.c | 12 +++++++++++- utils/gssd/krb5_util.c | 6 +++++- utils/gssd/krb5_util.h | 1 + 3 files changed, 17 insertions(+), 2 deletions(-) diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c index ccadb07..fff9d21 100644 --- a/utils/gssd/gssd.c +++ b/utils/gssd/gssd.c @@ -100,9 +100,14 @@ main(int argc, char *argv[]) int i; extern char *optarg; char *progname; +#ifdef HAVE_SET_ALLOWABLE_ENCTYPES + const char *opts = "fvrmnMp:k:d:t:R:l"; +#else + const char *opts = "fvrmnMp:k:d:t:R"; +#endif memset(ccachesearch, 0, sizeof(ccachesearch)); - while ((opt = getopt(argc, argv, "fvrmnMp:k:d:t:R:")) != -1) { + while ((opt = getopt(argc, argv, opts)) != -1) { switch (opt) { case 'f': fg = 1; @@ -143,6 +148,11 @@ main(int argc, char *argv[]) case 'R': preferred_realm = strdup(optarg); break; +#ifdef HAVE_SET_ALLOWABLE_ENCTYPES + case 'l': + limit_to_legacy_enctypes = 1; + break; +#endif default: usage(argv[0]); break; diff --git a/utils/gssd/krb5_util.c b/utils/gssd/krb5_util.c index 4b13fa1..887d118 100644 --- a/utils/gssd/krb5_util.c +++ b/utils/gssd/krb5_util.c @@ -129,6 +129,10 @@ /* Global list of principals/cache file names for machine credentials */ struct gssd_k5_kt_princ *gssd_k5_kt_princ_list = NULL; +#ifdef HAVE_SET_ALLOWABLE_ENCTYPES +int limit_to_legacy_enctypes = 0; +#endif + /*==========================*/ /*=== Internal routines ===*/ /*==========================*/ @@ -1342,7 +1346,7 @@ limit_krb5_enctypes(struct rpc_gss_sec *sec) * If we failed for any reason to produce global * list of supported enctypes, use local default here. */ - if (krb5_enctypes == NULL) + if (krb5_enctypes == NULL || limit_to_legacy_enctypes) maj_stat = gss_set_allowable_enctypes(&min_stat, credh, &krb5oid, num_enctypes, enctypes); else diff --git a/utils/gssd/krb5_util.h b/utils/gssd/krb5_util.h index b42b91e..cd6e107 100644 --- a/utils/gssd/krb5_util.h +++ b/utils/gssd/krb5_util.h @@ -36,6 +36,7 @@ char *gssd_k5_err_msg(krb5_context context, krb5_error_code code); void gssd_k5_get_default_realm(char **def_realm); #ifdef HAVE_SET_ALLOWABLE_ENCTYPES +extern int limit_to_legacy_enctypes; int limit_krb5_enctypes(struct rpc_gss_sec *sec); #endif -- 1.7.3.4 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-03-12 20:02 NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server Michael Weiser @ 2012-03-12 20:24 ` Jim Rees 2012-03-12 21:10 ` Kevin Coffman 1 sibling, 0 replies; 17+ messages in thread From: Jim Rees @ 2012-03-12 20:24 UTC (permalink / raw) To: Michael Weiser; +Cc: linux-nfs Michael Weiser wrote: A direct workaround is to set the following options in /etc/krb5.conf of client and server: [libdefaults] default_tkt_enctypes = des-cbc-md5 permitted_enctypes = des-cbc-md5 , add des-cbc-md5 keys to the keytabs of both machines and allow Single DES for both machines' principals on the KDC (MS AD 2008r2 in particular wants it enabled explicitly). This however not only limits the encryption types of session keys but all tickets as well and applies to the whole machine not just the NFSv4 service. This has a needlessly high security impact on both machines. Could this go in an appdefaults clause instead? My guess is not. I remember having to add allow_weak_crypto to libdefaults instead of appdefaults. But I thought I'd ask. If not, a command line argument to gssd seems reasonable. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-03-12 20:02 NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server Michael Weiser 2012-03-12 20:24 ` Jim Rees @ 2012-03-12 21:10 ` Kevin Coffman 2012-03-12 21:57 ` Michael Weiser 1 sibling, 1 reply; 17+ messages in thread From: Kevin Coffman @ 2012-03-12 21:10 UTC (permalink / raw) To: Michael Weiser; +Cc: linux-nfs On Mon, Mar 12, 2012 at 4:02 PM, Michael Weiser <M.Weiser@science-computing.de> wrote: > Hi, > > from what I can gather, nfs-utils-1.2.3 introduced support for > encryption other than Single DES for NFSv4: Previously, gssd would > proactively limit Kerberos encryption types of session keys to > des-cbc-crc (and perhaps -md5 and -md4). So while the actual ticket > might be encrypted using something way stronger, the included session > key would only be Single DES. > > Due to this self-limitation of the client, the server would never get > anything else than Single DES session keys and therefore needed no > mechanism of working around the problems caused by stronger session keys > with a kernel that does not support them. > > Beginning with version 1.2.3 of nfs-utils, gssd does no longer limits > itself to Single DES. Instead, it detects the encryption types supported > by the *client's* kernel and limits the session key's encryption type to > those reported as supported. This, however, ignores the fact, that the > *server's* kernel might not support them. Since the userspace of the > server (svcgssd) does not check what its kernel supports and has no > mechanism of renegotiating with the client, it happily accepts stronger > encryption types and tries to push them into the kernel. > > nfs-utils-1.2.4 includes a patch to svcgssd that uses > /proc/fs/nfsd/supported_encryption_types of newer kernels (2.6.35+ ?) to > determine the encryption types supported by the server's kernel and uses > subkey negotiation of current MIT Kerberos versions (1.9.1+) to > negotiate a possibly weaker encryption type with the client. While this > is a good solution for future enhancements and backwards compatibility > from now on it still leaves all the older installations with a problem. > RHEL5 for example only has MIT Kerberos 1.6 and will therefore most > likely never benefit from this fix. > > A direct workaround is to set the following options in /etc/krb5.conf of > client and server: > > [libdefaults] > default_tkt_enctypes = des-cbc-md5 > permitted_enctypes = des-cbc-md5 > > , add des-cbc-md5 keys to the keytabs of both machines and allow Single > DES for both machines' principals on the KDC (MS AD 2008r2 in particular > wants it enabled explicitly). This however not only limits the > encryption types of session keys but all tickets as well and applies to > the whole machine not just the NFSv4 service. This has a needlessly high > security impact on both machines. > > I quickly implemented a more self-contained fix that adds an option -l > to rpc.gssd that effectively reverts it to legacy behaviour: It ignores > its local kernel's capabilities and uses just Single DES. This option > could be set in e.g. /etc/sysconfig/nfs:GSSDARGS on all RHEL6 clients > that need to work with RHEL5 servers. It could possibly be enhanced to > be configurable on a per-machine basis. Inclusion of this or a similar > patch would be greatly appreciated. > > Obviously this is just a proof-of-concept and still needs some > polishing. I was just wondering if my reasoning is sound and the > solution acceptable. > > Thanks in advance, To summarize, the base issue was not with gssd/svcgssd. It was a change in the Kerberos library code (if I recall correctly, in 1.7 or 1.8??) which ignores the limited enctypes in the server's keytab, and instead uses the Kerberos library's capabilities to assert a subkey. A proper fix needs to be on the server. (Remember that non-Linux clients may be trying to use that RHEL5 server, and have no such mechanism to limit the requested enctypes.) AFAIK, the only way to properly "fix" the issue is at the server by adding "permitted_enctypes = des-cbc-md5" in krb5.conf. This does have the downside of limiting all services to DES, as you've stated. I don't know if patches for Kerberos and nfs-utils could be pulled up to RHEL5. IMHO, that would be the ideal solution. K.C. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-03-12 21:10 ` Kevin Coffman @ 2012-03-12 21:57 ` Michael Weiser 2012-03-13 13:51 ` Kevin Coffman 0 siblings, 1 reply; 17+ messages in thread From: Michael Weiser @ 2012-03-12 21:57 UTC (permalink / raw) To: Kevin Coffman; +Cc: linux-nfs Hello Kevin, On Mon, March 12, 2012 22:10, Kevin Coffman wrote: > To summarize, the base issue was not with gssd/svcgssd. It was a > change in the Kerberos library code (if I recall correctly, in 1.7 or > 1.8??) which ignores the limited enctypes in the server's keytab, and > instead uses the Kerberos library's capabilities to assert a subkey. Are you asking or telling? >From my understanding up until RFC 4537 (Kerberos Cryptosystem Negotiation Extension - which I hadn't heard of up until the day before yesterday), a kerberised service had no mechanism to negotiate a ticket or session key enctype with the client. This limitation is inherent to the Kerberos protocol since the KDC at the time of creating both has no way of asking the service which encryption types it currently supports. Instead, when adding the service to the realm, a set of keys is put on the KDC and into the service's keytab, thus only indirectly telling both, what enctypes the service supports. This seems to be exactly what the RFC's introduction (http://tools.ietf.org/html/rfc4537#section-1) explains, although it focusses on negotiating *stronger* encryption than what the KDC believes the service supports. So the proper workaround would be on the KDC by disabling all encryption types but Single DES for the service's principal. Since this is somewhat cumbersome in AD I instead just limited the client using the default_tkt_enctypes and permitted_enctypes options. The main problem I have with that, is that this degrades the encryption type of the tickets as well. I know of no option to tell an MIT or AD KDC to just limit the session key enctype to Single DES but encrypt the ticket with AES256. So to keep my NFSv4 setup working with the newer version of nfs-utils I actually have to make it even less secure. Another possible workaround would be just setting permitted_enctypes = des-cbc-md5 on the client and with perhaps a custom krb5.conf just for nfs-utils. But in my tests, setting just permitted_enctypes and no default_tkt_enctypes had no effect. This might be some AD speciality, though, that I haven't tracked down yet. > A proper fix needs to be on the server. (Remember that non-Linux > clients may be trying to use that RHEL5 server, and have no such > mechanism to limit the requested enctypes.) I would agree, if it could be done without subkey negotiation. Please tell me, I'm wrong. > AFAIK, the only way to properly "fix" the issue is at the server by > adding "permitted_enctypes = des-cbc-md5" in krb5.conf. This does > have the downside of limiting all services to DES, as you've stated. Because the server has no way of telling the client of this limitation, the client will still obtain e.g. an arcfour ticket with arcfour session key inside and present it to the server. Instead of the kernel saying "gss_kerberos_mech: unsupported algorithm 23" svcgssd will say "Encryption type not permitted" (or suchlike). The mount will still fail. Or not? It's my experience so far, at least, and corresponds to my knowledge of how Kerberos works. > I don't know if patches for Kerberos and nfs-utils could be pulled up > to RHEL5. IMHO, that would be the ideal solution. Yeah, that would be great. But I suspect, RFC4537-support from mit-krb5-1.9 is somewhat more than a houndret lines of code and not very backport-friendly. Also, this would need to be done in every Linux distribution for all sorts of combinations of nfs-utils and mit-krb5. A nice self-contained patch to nfs-utils or even just some krb5.conf-[appdefaults]-magic seems a lot more friendly to me. I wonder whether the client could securely apply a heuristic encryption type detection: First it would try the strongest available encryption type. If that didn't work, it'd try the next and so on down to Single DES (if permitted in /etc/krb5.conf). But apart from the performance impact I see the problem of an attacker interfering with the first few packets of a mount to degrade authentication and encryption of a connection from aes256 to des-cbc-crc. Thanks, Micha -- Michael Weiser science + computing ag Senior Systems Engineer Geschaeftsstelle Duesseldorf Martinstrasse 47-55, Haus A phone: +49 211 302 708 32 D-40223 Duesseldorf fax: +49 211 302 708 50 www.science-computing.de -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-03-12 21:57 ` Michael Weiser @ 2012-03-13 13:51 ` Kevin Coffman 2012-03-13 14:42 ` Michael Weiser 0 siblings, 1 reply; 17+ messages in thread From: Kevin Coffman @ 2012-03-13 13:51 UTC (permalink / raw) To: Michael Weiser; +Cc: linux-nfs On Mon, Mar 12, 2012 at 5:57 PM, Michael Weiser <M.Weiser@science-computing.de> wrote: > Hello Kevin, > > On Mon, March 12, 2012 22:10, Kevin Coffman wrote: > >> To summarize, the base issue was not with gssd/svcgssd. It was a >> change in the Kerberos library code (if I recall correctly, in 1.7 or >> 1.8??) which ignores the limited enctypes in the server's keytab, and >> instead uses the Kerberos library's capabilities to assert a subkey. > > Are you asking or telling? I'm telling about what happened. I don't recall what version the change was introduced. > From my understanding up until RFC 4537 (Kerberos Cryptosystem Negotiation > Extension - which I hadn't heard of up until the day before yesterday), a > kerberised service had no mechanism to negotiate a ticket or session key > enctype with the client. This limitation is inherent to the Kerberos > protocol since the KDC at the time of creating both has no way of asking > the service which encryption types it currently supports. Instead, when > adding the service to the realm, a set of keys is put on the KDC and into > the service's keytab, thus only indirectly telling both, what enctypes the > service supports. Prior to the change, the KDC knew what enctypes were in the service's keytab and would limit the enctypes negotiated for the service. After the change, the service asserts enctypes based on the Kerberos library's capabilities, not on what the service can actually handle. > This seems to be exactly what the RFC's introduction > (http://tools.ietf.org/html/rfc4537#section-1) explains, although it > focusses on negotiating *stronger* encryption than what the KDC believes > the service supports. > > So the proper workaround would be on the KDC by disabling all encryption > types but Single DES for the service's principal. Since this is somewhat > cumbersome in AD I instead just limited the client using the > default_tkt_enctypes and permitted_enctypes options. > > The main problem I have with that, is that this degrades the encryption > type of the tickets as well. I know of no option to tell an MIT or AD KDC > to just limit the session key enctype to Single DES but encrypt the ticket > with AES256. So to keep my NFSv4 setup working with the newer version of > nfs-utils I actually have to make it even less secure. > > Another possible workaround would be just setting permitted_enctypes = > des-cbc-md5 on the client and with perhaps a custom krb5.conf just for > nfs-utils. But in my tests, setting just permitted_enctypes and no > default_tkt_enctypes had no effect. This might be some AD speciality, > though, that I haven't tracked down yet. > >> A proper fix needs to be on the server. (Remember that non-Linux >> clients may be trying to use that RHEL5 server, and have no such >> mechanism to limit the requested enctypes.) > > I would agree, if it could be done without subkey negotiation. Please tell > me, I'm wrong. > >> AFAIK, the only way to properly "fix" the issue is at the server by >> adding "permitted_enctypes = des-cbc-md5" in krb5.conf. This does >> have the downside of limiting all services to DES, as you've stated. > > Because the server has no way of telling the client of this limitation, > the client will still obtain e.g. an arcfour ticket with arcfour session > key inside and present it to the server. Instead of the kernel saying > "gss_kerberos_mech: unsupported algorithm 23" svcgssd will say "Encryption > type not permitted" (or suchlike). The mount will still fail. Or not? It's > my experience so far, at least, and corresponds to my knowledge of how > Kerberos works. > >> I don't know if patches for Kerberos and nfs-utils could be pulled up >> to RHEL5. IMHO, that would be the ideal solution. > > Yeah, that would be great. But I suspect, RFC4537-support from > mit-krb5-1.9 is somewhat more than a houndret lines of code and not very > backport-friendly. Also, this would need to be done in every Linux > distribution for all sorts of combinations of nfs-utils and mit-krb5. A > nice self-contained patch to nfs-utils or even just some > krb5.conf-[appdefaults]-magic seems a lot more friendly to me. The Kerberos changes to allow the server side to limit the the negotiated enctypes are not that extensive. The nfs-utils changes may be more than they are willing to include. > I wonder whether the client could securely apply a heuristic encryption > type detection: First it would try the strongest available encryption > type. If that didn't work, it'd try the next and so on down to Single DES > (if permitted in /etc/krb5.conf). But apart from the performance impact I > see the problem of an attacker interfering with the first few packets of a > mount to degrade authentication and encryption of a connection from aes256 > to des-cbc-crc. > > Thanks, > Micha I don't object to your change, but will assert that your suggested solution does not handle non-Linux clients attempting to use the RHEL5 server. K.C. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-03-13 13:51 ` Kevin Coffman @ 2012-03-13 14:42 ` Michael Weiser 2012-03-13 18:53 ` Kevin Coffman 0 siblings, 1 reply; 17+ messages in thread From: Michael Weiser @ 2012-03-13 14:42 UTC (permalink / raw) To: Kevin Coffman; +Cc: linux-nfs Hello Kevin, On Tue, Mar 13, 2012 at 09:51:46AM -0400, Kevin Coffman wrote: > >> To summarize, the base issue was not with gssd/svcgssd. It was a > >> change in the Kerberos library code (if I recall correctly, in 1.7 or > >> 1.8??) which ignores the limited enctypes in the server's keytab, and > >> instead uses the Kerberos library's capabilities to assert a subkey. > > Are you asking or telling? > I'm telling about what happened. I don't recall what version the > change was introduced. > > From my understanding up until RFC 4537 (Kerberos Cryptosystem Negotiation > > Extension - which I hadn't heard of up until the day before yesterday), a > > kerberised service had no mechanism to negotiate a ticket or session key > > enctype with the client. This limitation is inherent to the Kerberos > > protocol since the KDC at the time of creating both has no way of asking > > the service which encryption types it currently supports. Instead, when > > adding the service to the realm, a set of keys is put on the KDC and into > > the service's keytab, thus only indirectly telling both, what enctypes the > > service supports. > Prior to the change, the KDC knew what enctypes were in the service's > keytab and would limit the enctypes negotiated for the service. After > the change, the service asserts enctypes based on the Kerberos > library's capabilities, not on what the service can actually handle. Do you mean the introduction of subkey negotiation on the client side without support for limiting the enctypes on the server side which was corrected by mit-krb5 1.9.1 and your commit d6c1b35c6b40243bfd6fba2591c9f8f2653078c0 to nfs-utils? Then I understand now, what you meant. With your fix, subkey negotiation should indeed work nicely if I have at least MIT Kerberos 1.7 and nfs-utils-1.2.3 on the client and MIT Kerberos 1.9.1 and nfs-utils-1.2.4 on the server. (It does however not do so with current Debian packages that have both fixes backported to MIT Kerberos 1.8.3 and nfs-utils-1.2.2, but that's a different story.) Unfortunetely all this is not my actual problem: What I'm seeing is that gssd of nfs-utils-1.2.3 no longer limits itself to Single DES session keys causing grief for an svcgssd that runs on a kernel that doesn't support anything other than Single DES. This is not due to subkey negotiation because the server only has MIT Kerberos 1.6 and nfs-utils-1.0.9 which don't even support it. It is also not due to a change on the KDC: All clients have always had aes256 and arcfour keys in their keytabs and as long as they have older versions of nfs-utils they work just fine with them. For this case I need to limit gssd to Single DES *for session keys only* even though it wants to do more. Since subkey negotiation can't be used since Kerberos and nfs-utils on the server are too old, I need to do it on the client. You are right: I could limit the encryption types on the KDC and in the client's keytab to Single DES. The nfs-utils gssd has however for some time been bright enough to get tickets with stronger encryption types but only Single DES session keys inside. I'd like to preserve that behaviour because I expect it has a noticeable security impact. It also has an administrative impact: Nowadays, Active Directory needs a change to the security policy to even hand out Single DES encrypted tickets while it is perfectly happy to hand out arcfour tickets with Single DES session keys inside (without a change to the policy). So basically, the new behaviour of nfs-utils' gssd will cause grief for NFS administrators in AD environments while it would continue to work with only client-side changes if the old gssd behaviour could be forced somehow. I expect it's the same with any newly set-up MIT or Heimdal KDC that has Single DES disabled by default. > I don't object to your change, but will assert that your suggested > solution does not handle non-Linux clients attempting to use the RHEL5 > server. As far as I can see, this has always been the case: A solaris client presenting a RHEL5 server with an arcfour session key would not be able to mount. So I guess for Solaris clients I'd already have limited encryption types on the KDC to Single DES so that the Solaris client only gets Single DES session keys *and tickets*. Or the Solaris client has logic similar to what gssd used to do which limits the session key type to Single DES. I'll ask a collegue who actually runs a Solaris box to see what it's doing. Thanks for your patience, Micha -- Michael Weiser science + computing ag Senior Systems Engineer Geschaeftsstelle Duesseldorf Martinstrasse 47-55, Haus A phone: +49 211 302 708 32 D-40223 Duesseldorf fax: +49 211 302 708 50 www.science-computing.de -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-03-13 14:42 ` Michael Weiser @ 2012-03-13 18:53 ` Kevin Coffman 2012-03-14 13:48 ` Michael Weiser 0 siblings, 1 reply; 17+ messages in thread From: Kevin Coffman @ 2012-03-13 18:53 UTC (permalink / raw) To: Michael Weiser; +Cc: linux-nfs On Tue, Mar 13, 2012 at 10:42 AM, Michael Weiser <M.Weiser@science-computing.de> wrote: > Hello Kevin, > > On Tue, Mar 13, 2012 at 09:51:46AM -0400, Kevin Coffman wrote: > >> >> To summarize, the base issue was not with gssd/svcgssd. It was a >> >> change in the Kerberos library code (if I recall correctly, in 1.7 or >> >> 1.8??) which ignores the limited enctypes in the server's keytab, and >> >> instead uses the Kerberos library's capabilities to assert a subkey. >> > Are you asking or telling? >> I'm telling about what happened. I don't recall what version the >> change was introduced. > >> > From my understanding up until RFC 4537 (Kerberos Cryptosystem Negotiation >> > Extension - which I hadn't heard of up until the day before yesterday), a >> > kerberised service had no mechanism to negotiate a ticket or session key >> > enctype with the client. This limitation is inherent to the Kerberos >> > protocol since the KDC at the time of creating both has no way of asking >> > the service which encryption types it currently supports. Instead, when >> > adding the service to the realm, a set of keys is put on the KDC and into >> > the service's keytab, thus only indirectly telling both, what enctypes the >> > service supports. >> Prior to the change, the KDC knew what enctypes were in the service's >> keytab and would limit the enctypes negotiated for the service. After >> the change, the service asserts enctypes based on the Kerberos >> library's capabilities, not on what the service can actually handle. > > Do you mean the introduction of subkey negotiation on the client side > without support for limiting the enctypes on the server side which was > corrected by mit-krb5 1.9.1 and your commit > d6c1b35c6b40243bfd6fba2591c9f8f2653078c0 to nfs-utils? Hi Michael, My understanding of the subkey negotiation is that the subkey is asserted by the server, not the client. If the client says it only supports DES, then that will indeed limit what subkey the server's Kerberos library will assert. > Then I understand now, what you meant. With your fix, subkey negotiation > should indeed work nicely if I have at least MIT Kerberos 1.7 and > nfs-utils-1.2.3 on the client and MIT Kerberos 1.9.1 and nfs-utils-1.2.4 > on the server. (It does however not do so with current Debian packages > that have both fixes backported to MIT Kerberos 1.8.3 and > nfs-utils-1.2.2, but that's a different story.) > > Unfortunetely all this is not my actual problem: What I'm seeing is that > gssd of nfs-utils-1.2.3 no longer limits itself to Single DES session > keys causing grief for an svcgssd that runs on a kernel that doesn't > support anything other than Single DES. This is not due to subkey > negotiation because the server only has MIT Kerberos 1.6 and > nfs-utils-1.0.9 which don't even support it. It is also not due to a > change on the KDC: All clients have always had aes256 and arcfour keys > in their keytabs and as long as they have older versions of nfs-utils > they work just fine with them. > > For this case I need to limit gssd to Single DES *for session keys only* > even though it wants to do more. Since subkey negotiation can't be used > since Kerberos and nfs-utils on the server are too old, I need to do it > on the client. > > You are right: I could limit the encryption types on the KDC and in the > client's keytab to Single DES. The nfs-utils gssd has however for some > time been bright enough to get tickets with stronger encryption types > but only Single DES session keys inside. I'd like to preserve that > behaviour because I expect it has a noticeable security impact. > > It also has an administrative impact: Nowadays, Active Directory needs a > change to the security policy to even hand out Single DES encrypted > tickets while it is perfectly happy to hand out arcfour tickets with > Single DES session keys inside (without a change to the policy). So > basically, the new behaviour of nfs-utils' gssd will cause grief for NFS > administrators in AD environments while it would continue to work with > only client-side changes if the old gssd behaviour could be forced > somehow. I expect it's the same with any newly set-up MIT or Heimdal KDC > that has Single DES disabled by default. > >> I don't object to your change, but will assert that your suggested >> solution does not handle non-Linux clients attempting to use the RHEL5 >> server. > > As far as I can see, this has always been the case: A solaris client > presenting a RHEL5 server with an arcfour session key would not be able > to mount. So I guess for Solaris clients I'd already have limited > encryption types on the KDC to Single DES so that the Solaris client > only gets Single DES session keys *and tickets*. Or the Solaris client > has logic similar to what gssd used to do which limits the session key > type to Single DES. I'll ask a collegue who actually runs a Solaris box > to see what it's doing. > > Thanks for your patience, > Micha The way things should work is that the client limits what enctypes it negotiates based on the enctypes it can handle. The server does the same. Before subkeys, the way to limit the enctypes on the server was to issue the keytab with only the enctypes supported. The KDC knew what types were included in the server's keytab and issued the ticket with a session key with that limitation in mind. The extra code to limit enctypes was added to the client because it had no such mechanism. After subkeys, the server's keytab enctypes are still honored by the KDC, however the server's Kerberos libraries assert a subkey based on the enctypes supported by the libraries, ignoring the enctypes in the keytab. That required the additional support to limit the enctypes on the server side as well. It sounds like you are saying that your RHEL5 NFS server has a keytab with more than a DES key. If that is true, I think that is the issue. Not with the clients. K.C. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-03-13 18:53 ` Kevin Coffman @ 2012-03-14 13:48 ` Michael Weiser 2012-03-19 13:00 ` Michael Weiser 0 siblings, 1 reply; 17+ messages in thread From: Michael Weiser @ 2012-03-14 13:48 UTC (permalink / raw) To: Kevin Coffman; +Cc: linux-nfs Hi Kevin, On Tue, Mar 13, 2012 at 02:53:46PM -0400, Kevin Coffman wrote: > It sounds like you are saying that your RHEL5 NFS server has a keytab > with more than a DES key. If that is true, I think that is the issue. > Not with the clients. Yes, this is what I've been talking about: I have only aes256-cts and arcfour-hmac keys in the keytabs of client and server: [root@rhel5s1 etc]# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE (AES-256 CTS mode with 96-bit SHA-1 HMAC) 2 nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE (ArcFour with HMAC/md5) and no configuration in /etc/krb5.conf whatsoever: [root@rhel5s1 ~]# cat /etc/krb5.conf [libdefaults] default_realm = MYDOMAIN.EXAMPLE With this configuration the mount works just fine (in this example the server is its own client): [root@rhel5s1 ~]# mount -t nfs4 -o sec=krb5 rhel5s1:/ /mnt/ gssd gets the following tickets (I had to disable a patch in RHEL5's nfs-utils and recompile to get the ticket cache file in /tmp because they've patched it to keep it in memory): [root@rhel5s1 ~]# klist -e /tmp/krb5cc_machine_MYDOMAIN.EXAMPLE Ticket cache: FILE:/tmp/krb5cc_machine_MYDOMAIN.EXAMPLE Default principal: nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE Valid starting Expires Service principal 03/14/12 13:53:32 03/14/12 23:53:32 krbtgt/MYDOMAIN.EXAMPLE@MYDOMAIN.EXAMPLE renew until 03/15/12 13:53:32, Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC 03/14/12 13:53:32 03/14/12 23:53:32 nfs/rhel5s1.mydomain.example@ renew until 03/15/12 13:53:32, Etype (skey, tkt): DES cbc mode with CRC-32, ArcFour with HMAC/md5 So the client's ticket for the server is encrypted using arcfour-hmac but the session key contained therein is only des-cbc-crc. When accessing the mount, gssd gets the following ticket for the user: [root@rhel5s1 ~]# su - user01 -sh-3.2$ kinit Password for user01@MYDOMAIN.EXAMPLE: -sh-3.2$ ls /mnt blub projects -sh-3.2$ klist -e Ticket cache: FILE:/tmp/krb5cc_10100 Default principal: user01@MYDOMAIN.EXAMPLE Valid starting Expires Service principal 03/14/12 13:57:25 03/14/12 23:57:27 krbtgt/MYDOMAIN.EXAMPLE@MYDOMAIN.EXAMPLE renew until 03/15/12 13:57:25, Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC 03/14/12 13:57:34 03/14/12 23:57:27 nfs/rhel5s1.mydomain.example@ renew until 03/15/12 13:57:25, Etype (skey, tkt): DES cbc mode with CRC-32, ArcFour with HMAC/md5 This behaviour works so seamlessly, that I had assumed, it's intentional. Are you telling me, that it is neither intended nor supported? If so: Isn't this something we'd want to have? I accept that it's not much use from an interoperability point of view but it sure simplifies administration in a Linux-only environment. Doesn't this also have at least some positive security impact? And as I've said, it greatly simplifies Linux admins' life in an Active Directory 2008 R2+ environment where AD administrators will be very reluctant to change the domain security policy for those obscure Linux boxes. For completeness' sake: The RHEL6 client does not limit the session key to Single DES and therefore the mount fails: [root@rhel6 ~]# klist -e /tmp/krb5cc_machine_MYDOMAIN.EXAMPLE Ticket cache: FILE:/tmp/krb5cc_machine_MYDOMAIN.EXAMPLE Default principal: nfs/rhel6.mydomain.example@MYDOMAIN.EXAMPLE Valid starting Expires Service principal 03/14/12 14:00:19 03/15/12 00:00:20 krbtgt/MYDOMAIN.EXAMPLE@MYDOMAIN.EXAMPLE renew until 03/21/12 14:00:19, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 03/14/12 14:00:20 03/15/12 00:00:20 nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE renew until 03/21/12 14:00:19, Etype (skey, tkt): arcfour-hmac, arcfour-hmac Limiting the service account to Single DES on the KDC, putting just a des-cbc-crc key in the server's keytab and adding allow_weak_crypto = true to /etc/krb5.conf makes the mount work and yields the following machine ticket cache on the client: [root@rhel6 ~]# klist -e /tmp/krb5cc_machine_MYDOMAIN.EXAMPLE Ticket cache: FILE:/tmp/krb5cc_machine_MYDOMAIN.EXAMPLE Default principal: nfs/rhel6.mydomain.example@MYDOMAIN.EXAMPLE Valid starting Expires Service principal 03/14/12 14:04:48 03/15/12 00:04:48 krbtgt/MYDOMAIN.EXAMPLE@MYDOMAIN.EXAMPLE renew until 03/21/12 14:04:48, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 03/14/12 14:04:48 03/15/12 00:04:48 nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE renew until 03/21/12 14:04:48, Etype (skey, tkt): des-cbc-crc, des-cbc-md5 For some funny reason, with my AD 2008R2 KDC, the ticket is encrypted with des-cbc-md5 but accepted by the server anyway. The user accessing the mount also gets just a des-cbc-crc/md5 ticket: [user01@rhel6 ~]$ klist -e Ticket cache: FILE:/tmp/krb5cc_500 Default principal: user01@MYDOMAIN.EXAMPLE Valid starting Expires Service principal 03/14/12 14:08:48 03/15/12 00:08:50 krbtgt/MYDOMAIN.EXAMPLE@MYDOMAIN.EXAMPLE renew until 03/21/12 14:08:48, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 03/14/12 14:08:52 03/15/12 00:08:50 nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE renew until 03/21/12 14:08:48, Etype (skey, tkt): des-cbc-crc, des-cbc-md5 With my legacy behaviour patch, RHEL6's gssd behaves like RHEL5's and gets arcfour-encrypted tickets with des-cbc-crc session keys inside: 1. put stronger keys back into krb5.keytab of RHEL5 server 2. allow stronger encryption types for servers service account on KDC [root@rhel6 ~]# rpc.gssd -l -vvv [root@rhel6 ~]# mount -o vers=4,sec=krb5 rhel5s1:/ /mnt [root@rhel6 ~]# klist -e /tmp/krb5cc_machine_MYDOMAIN.EXAMPLE Ticket cache: FILE:/tmp/krb5cc_machine_MYDOMAIN.EXAMPLE Default principal: nfs/rhel6.mydomain.example@MYDOMAIN.EXAMPLE Valid starting Expires Service principal 03/14/12 14:17:28 03/15/12 00:17:28 krbtgt/MYDOMAIN.EXAMPLE@MYDOMAIN.EXAMPLE renew until 03/21/12 14:17:28, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 03/14/12 14:17:28 03/15/12 00:17:28 nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE renew until 03/21/12 14:17:28, Etype (skey, tkt): des-cbc-crc, arcfour-hmac Same for a user: [root@rhel6 ~]# su - user01 [user01@rhel6 ~]$ kinit Password for user01@MYDOMAIN.EXAMPLE: [user01@rhel6 ~]$ ls /mnt blub projects [user01@rhel6 ~]$ klist -e Ticket cache: FILE:/tmp/krb5cc_500 Default principal: user01@MYDOMAIN.EXAMPLE Valid starting Expires Service principal 03/14/12 14:18:52 03/15/12 00:18:53 krbtgt/MYDOMAIN.EXAMPLE@MYDOMAIN.EXAMPLE renew until 03/21/12 14:18:52, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 03/14/12 14:18:56 03/15/12 00:18:53 nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE renew until 03/21/12 14:18:52, Etype (skey, tkt): des-cbc-crc, arcfour-hmac Thanks, -- Michael Weiser science + computing ag Senior Systems Engineer Geschaeftsstelle Duesseldorf Martinstrasse 47-55, Haus A phone: +49 211 302 708 32 D-40223 Duesseldorf fax: +49 211 302 708 50 www.science-computing.de -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-03-14 13:48 ` Michael Weiser @ 2012-03-19 13:00 ` Michael Weiser 2012-03-20 11:27 ` Steve Dickson 0 siblings, 1 reply; 17+ messages in thread From: Michael Weiser @ 2012-03-19 13:00 UTC (permalink / raw) To: Kevin Coffman; +Cc: linux-nfs Hello Kevin, Hello list, On Wed, Mar 14, 2012 at 02:48:29PM +0100, Michael Weiser wrote: > So the client's ticket for the server is encrypted using arcfour-hmac > but the session key contained therein is only des-cbc-crc. > This behaviour works so seamlessly, that I had assumed, it's intentional. > Are you telling me, that it is neither intended nor supported? > If so: Isn't this something we'd want to have? I accept that it's not > much use from an interoperability point of view but it sure simplifies > administration in a Linux-only environment. Doesn't this also have at > least some positive security impact? And as I've said, it greatly > simplifies Linux admins' life in an Active Directory 2008 R2+ > environment where AD administrators will be very reluctant to change the > domain security policy for those obscure Linux boxes. Any thoughts on this, anyone? If nobody objects, I'd resubmit my patch to gssd with some cleanup and documentation. Thanks, -- Michael Weiser science + computing ag Senior Systems Engineer Geschaeftsstelle Duesseldorf Martinstrasse 47-55, Haus A phone: +49 211 302 708 32 D-40223 Duesseldorf fax: +49 211 302 708 50 www.science-computing.de -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-03-19 13:00 ` Michael Weiser @ 2012-03-20 11:27 ` Steve Dickson 2012-03-20 17:44 ` Michael Weiser 0 siblings, 1 reply; 17+ messages in thread From: Steve Dickson @ 2012-03-20 11:27 UTC (permalink / raw) To: Michael Weiser; +Cc: Kevin Coffman, linux-nfs Hello, On 03/19/2012 09:00 AM, Michael Weiser wrote: > Hello Kevin, > Hello list, > > On Wed, Mar 14, 2012 at 02:48:29PM +0100, Michael Weiser wrote: > >> So the client's ticket for the server is encrypted using arcfour-hmac >> but the session key contained therein is only des-cbc-crc. > >> This behaviour works so seamlessly, that I had assumed, it's intentional. >> Are you telling me, that it is neither intended nor supported? > >> If so: Isn't this something we'd want to have? I accept that it's not >> much use from an interoperability point of view but it sure simplifies >> administration in a Linux-only environment. Doesn't this also have at >> least some positive security impact? And as I've said, it greatly >> simplifies Linux admins' life in an Active Directory 2008 R2+ >> environment where AD administrators will be very reluctant to change the >> domain security policy for those obscure Linux boxes. > > Any thoughts on this, anyone? The fact you are making it simpler for admins is a good thing IMHO... > > If nobody objects, I'd resubmit my patch to gssd with some cleanup and > documentation.\ No, Please do... steved. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-03-20 11:27 ` Steve Dickson @ 2012-03-20 17:44 ` Michael Weiser 2012-03-29 14:02 ` Michael Weiser 0 siblings, 1 reply; 17+ messages in thread From: Michael Weiser @ 2012-03-20 17:44 UTC (permalink / raw) To: Steve Dickson; +Cc: Kevin Coffman, linux-nfs [-- Attachment #1: Type: text/plain, Size: 1151 bytes --] Hi Steve, On Tue, Mar 20, 2012 at 07:27:18AM -0400, Steve Dickson wrote: > > If nobody objects, I'd resubmit my patch to gssd with some cleanup and > > documentation.\ > No, Please do... Here's the patch. Is there any special procedure to follow to get it committed? I just noticed that while the code bits are optional based on HAVE_SET_ALLOWABLE_ENCTYPES, the man page part isn't. I've got no idea, how to go about that. Tanks, -- Michael Weiser science + computing ag Senior Systems Engineer Geschaeftsstelle Duesseldorf Martinstrasse 47-55, Haus A phone: +49 211 302 708 32 D-40223 Duesseldorf fax: +49 211 302 708 50 www.science-computing.de -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 [-- Attachment #2: 0001-Add-l-option-to-gssd-to-force-legacy-behaviour.patch --] [-- Type: text/x-diff, Size: 5027 bytes --] >From 6073594c72b7664b3c2534314fe6e83d30d7f78c Mon Sep 17 00:00:00 2001 From: Michael Weiser <weiser@science-computing.de> Date: Tue, 20 Mar 2012 18:19:58 +0100 Subject: [PATCH] Add -l option to gssd to force legacy behaviour Implement a new option -l to force gssd to ignore its kernel's crypto capabilities and use just the Single DES legacy encryption types to be compatible with old servers. This is only relevant if those servers have strong keys in their keytab. --- utils/gssd/gssd.c | 15 +++++++++++++-- utils/gssd/gssd.man | 22 +++++++++++++++++++++- utils/gssd/krb5_util.c | 6 +++++- utils/gssd/krb5_util.h | 1 + 4 files changed, 40 insertions(+), 4 deletions(-) diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c index ccadb07..e873af1 100644 --- a/utils/gssd/gssd.c +++ b/utils/gssd/gssd.c @@ -55,6 +55,10 @@ #include "gss_util.h" #include "krb5_util.h" +#ifdef HAVE_SET_ALLOWABLE_ENCTYPES +#define OPTS_ENCTYPES "l" +#define USAGE_ENCTYPES " [-l]" +#endif char pipefs_dir[PATH_MAX] = GSSD_PIPEFS_DIR; char keytabfile[PATH_MAX] = GSSD_DEFAULT_KEYTAB_FILE; char ccachedir[PATH_MAX] = GSSD_DEFAULT_CRED_DIR; @@ -85,7 +89,8 @@ sig_hup(int signal) static void usage(char *progname) { - fprintf(stderr, "usage: %s [-f] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n", + fprintf(stderr, "usage: %s [-f]" USAGE_ENCTYPES + " [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n", progname); exit(1); } @@ -102,7 +107,8 @@ main(int argc, char *argv[]) char *progname; memset(ccachesearch, 0, sizeof(ccachesearch)); - while ((opt = getopt(argc, argv, "fvrmnMp:k:d:t:R:")) != -1) { + while ((opt = getopt(argc, argv, "fvrmnMp:k:d:t:R" + OPTS_ENCTYPES)) != -1) { switch (opt) { case 'f': fg = 1; @@ -143,6 +149,11 @@ main(int argc, char *argv[]) case 'R': preferred_realm = strdup(optarg); break; +#ifdef HAVE_SET_ALLOWABLE_ENCTYPES + case 'l': + limit_to_legacy_enctypes = 1; + break; +#endif default: usage(argv[0]); break; diff --git a/utils/gssd/gssd.man b/utils/gssd/gssd.man index 073379d..fd76bfe 100644 --- a/utils/gssd/gssd.man +++ b/utils/gssd/gssd.man @@ -6,7 +6,7 @@ .SH NAME rpc.gssd \- rpcsec_gss daemon .SH SYNOPSIS -.B "rpc.gssd [-f] [-n] [-k keytab] [-p pipefsdir] [-v] [-r] [-d ccachedir]" +.B "rpc.gssd [-f] [-n] [-k keytab] [-l] [-p pipefsdir] [-v] [-r] [-d ccachedir]" .SH DESCRIPTION The rpcsec_gss protocol gives a means of using the gss-api generic security api to provide security for protocols using rpc (in particular, nfs). Before @@ -70,6 +70,26 @@ for "machine credentials" is now: If this search order does not use the correct key then provide a keytab file that contains only correct keys. .TP +.B -l +Tells +.B rpc.gssd +to limit session keys to Single DES even if the kernel supports stronger +encryption types. Service ticket encryption is still governed by what +the KDC believes the target server supports. This way the client can +access a server that has strong keys in its keytab for ticket decryption +but whose kernel only supports Single DES. +.IP +The alternative is to put only Single DES keys in the server's keytab +and limit encryption types for its principal to Single DES on the KDC +which will cause service tickets for this server to be encrypted using +only Single DES and (as a side-effect) contain only Single DES session +keys. +.IP +This legacy behaviour is only required for older servers +(pre nfs-utils-1.2.4). If the server has a recent kernel, Kerberos +implementation and nfs-utils it will work just fine with stronger +encryption. +.TP .B -p path Tells .B rpc.gssd diff --git a/utils/gssd/krb5_util.c b/utils/gssd/krb5_util.c index 4b13fa1..887d118 100644 --- a/utils/gssd/krb5_util.c +++ b/utils/gssd/krb5_util.c @@ -129,6 +129,10 @@ /* Global list of principals/cache file names for machine credentials */ struct gssd_k5_kt_princ *gssd_k5_kt_princ_list = NULL; +#ifdef HAVE_SET_ALLOWABLE_ENCTYPES +int limit_to_legacy_enctypes = 0; +#endif + /*==========================*/ /*=== Internal routines ===*/ /*==========================*/ @@ -1342,7 +1346,7 @@ limit_krb5_enctypes(struct rpc_gss_sec *sec) * If we failed for any reason to produce global * list of supported enctypes, use local default here. */ - if (krb5_enctypes == NULL) + if (krb5_enctypes == NULL || limit_to_legacy_enctypes) maj_stat = gss_set_allowable_enctypes(&min_stat, credh, &krb5oid, num_enctypes, enctypes); else diff --git a/utils/gssd/krb5_util.h b/utils/gssd/krb5_util.h index b42b91e..cd6e107 100644 --- a/utils/gssd/krb5_util.h +++ b/utils/gssd/krb5_util.h @@ -36,6 +36,7 @@ char *gssd_k5_err_msg(krb5_context context, krb5_error_code code); void gssd_k5_get_default_realm(char **def_realm); #ifdef HAVE_SET_ALLOWABLE_ENCTYPES +extern int limit_to_legacy_enctypes; int limit_krb5_enctypes(struct rpc_gss_sec *sec); #endif -- 1.7.3.4 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-03-20 17:44 ` Michael Weiser @ 2012-03-29 14:02 ` Michael Weiser 2012-04-12 14:43 ` Steve Dickson 0 siblings, 1 reply; 17+ messages in thread From: Michael Weiser @ 2012-03-29 14:02 UTC (permalink / raw) To: Steve Dickson; +Cc: linux-nfs Hi Steve, On Tue, Mar 20, 2012 at 06:44:18PM +0100, Michael Weiser wrote: > > > If nobody objects, I'd resubmit my patch to gssd with some cleanup and > > > documentation.\ > > No, Please do... > Here's the patch. Is there any special procedure to follow to get it > committed? How do I go about getting this committed? > I just noticed that while the code bits are optional based on > HAVE_SET_ALLOWABLE_ENCTYPES, the man page part isn't. I've got no idea, > how to go about that. Thanks, -- Michael Weiser science + computing ag Senior Systems Engineer Geschaeftsstelle Duesseldorf Martinstrasse 47-55, Haus A phone: +49 211 302 708 32 D-40223 Duesseldorf fax: +49 211 302 708 50 www.science-computing.de -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-03-29 14:02 ` Michael Weiser @ 2012-04-12 14:43 ` Steve Dickson 2012-04-12 15:49 ` Michael Weiser 0 siblings, 1 reply; 17+ messages in thread From: Steve Dickson @ 2012-04-12 14:43 UTC (permalink / raw) To: Michael Weiser; +Cc: linux-nfs On 03/29/2012 10:02 AM, Michael Weiser wrote: > Hi Steve, > > On Tue, Mar 20, 2012 at 06:44:18PM +0100, Michael Weiser wrote: > >>>> If nobody objects, I'd resubmit my patch to gssd with some cleanup and >>>> documentation.\ >>> No, Please do... >> Here's the patch. Is there any special procedure to follow to get it >> committed? > > How do I go about getting this committed? My bad... I'm looking into this now.... > >> I just noticed that while the code bits are optional based on >> HAVE_SET_ALLOWABLE_ENCTYPES, the man page part isn't. I've got no idea, >> how to go about that. I'm think we should remove all those defines and have the code enabled by default. The main reason is defines like that just clutter up the code, plus there would be a needed for another configuration flag which I think is a bit over kill... steved. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-04-12 14:43 ` Steve Dickson @ 2012-04-12 15:49 ` Michael Weiser 2012-04-12 16:02 ` Steve Dickson 0 siblings, 1 reply; 17+ messages in thread From: Michael Weiser @ 2012-04-12 15:49 UTC (permalink / raw) To: Steve Dickson; +Cc: linux-nfs [-- Attachment #1: Type: text/plain, Size: 1575 bytes --] Hi Steve, On Thu, Apr 12, 2012 at 10:43:20AM -0400, Steve Dickson wrote: > > How do I go about getting this committed? > My bad... I'm looking into this now.... Thanks for getting back to me. > >> I just noticed that while the code bits are optional based on > >> HAVE_SET_ALLOWABLE_ENCTYPES, the man page part isn't. I've got no idea, > >> how to go about that. > I'm think we should remove all those defines and have the code enabled > by default. The main reason is defines like that just clutter up the > code, plus there would be a needed for another configuration flag > which I think is a bit over kill... Here it is. The whole HAVE_SET_ALLOWABLE_ENCTYPES logic is still in place but my code now ignores it. So with a GSSAPI implementation that doesn't support it, the -l switch will be accepted by gssd but silently do nothing. Thanks, -- Michael Weiser science + computing ag Senior Systems Engineer Geschaeftsstelle Duesseldorf Martinstrasse 47-55, Haus A phone: +49 211 302 708 32 D-40223 Duesseldorf fax: +49 211 302 708 50 www.science-computing.de -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 [-- Attachment #2: 0001-Add-l-option-to-gssd-to-force-legacy-behaviour.patch --] [-- Type: text/x-diff, Size: 4556 bytes --] >From 8ebaf42be06c87f52ca482dd954d4b710452e9e9 Mon Sep 17 00:00:00 2001 From: Michael Weiser <weiser@science-computing.de> Date: Thu, 12 Apr 2012 17:44:12 +0200 Subject: [PATCH] Add -l option to gssd to force legacy behaviour Implement a new option -l to force gssd to ignore its kernel's crypto capabilities and use just the Single DES legacy encryption types to be compatible with old servers. This is only relevant if those servers have strong keys in their keytab. --- utils/gssd/gssd.c | 7 +++++-- utils/gssd/gssd.man | 22 +++++++++++++++++++++- utils/gssd/krb5_util.c | 4 +++- utils/gssd/krb5_util.h | 1 + 4 files changed, 30 insertions(+), 4 deletions(-) diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c index d53795e..d4c18a7 100644 --- a/utils/gssd/gssd.c +++ b/utils/gssd/gssd.c @@ -85,7 +85,7 @@ sig_hup(int signal) static void usage(char *progname) { - fprintf(stderr, "usage: %s [-f] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n", + fprintf(stderr, "usage: %s [-f] [-l] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n", progname); exit(1); } @@ -102,7 +102,7 @@ main(int argc, char *argv[]) char *progname; memset(ccachesearch, 0, sizeof(ccachesearch)); - while ((opt = getopt(argc, argv, "fvrmnMp:k:d:t:R:")) != -1) { + while ((opt = getopt(argc, argv, "fvrmnMp:k:ld:t:R")) != -1) { switch (opt) { case 'f': fg = 1; @@ -143,6 +143,9 @@ main(int argc, char *argv[]) case 'R': preferred_realm = strdup(optarg); break; + case 'l': + limit_to_legacy_enctypes = 1; + break; default: usage(argv[0]); break; diff --git a/utils/gssd/gssd.man b/utils/gssd/gssd.man index 073379d..fd76bfe 100644 --- a/utils/gssd/gssd.man +++ b/utils/gssd/gssd.man @@ -6,7 +6,7 @@ .SH NAME rpc.gssd \- rpcsec_gss daemon .SH SYNOPSIS -.B "rpc.gssd [-f] [-n] [-k keytab] [-p pipefsdir] [-v] [-r] [-d ccachedir]" +.B "rpc.gssd [-f] [-n] [-k keytab] [-l] [-p pipefsdir] [-v] [-r] [-d ccachedir]" .SH DESCRIPTION The rpcsec_gss protocol gives a means of using the gss-api generic security api to provide security for protocols using rpc (in particular, nfs). Before @@ -70,6 +70,26 @@ for "machine credentials" is now: If this search order does not use the correct key then provide a keytab file that contains only correct keys. .TP +.B -l +Tells +.B rpc.gssd +to limit session keys to Single DES even if the kernel supports stronger +encryption types. Service ticket encryption is still governed by what +the KDC believes the target server supports. This way the client can +access a server that has strong keys in its keytab for ticket decryption +but whose kernel only supports Single DES. +.IP +The alternative is to put only Single DES keys in the server's keytab +and limit encryption types for its principal to Single DES on the KDC +which will cause service tickets for this server to be encrypted using +only Single DES and (as a side-effect) contain only Single DES session +keys. +.IP +This legacy behaviour is only required for older servers +(pre nfs-utils-1.2.4). If the server has a recent kernel, Kerberos +implementation and nfs-utils it will work just fine with stronger +encryption. +.TP .B -p path Tells .B rpc.gssd diff --git a/utils/gssd/krb5_util.c b/utils/gssd/krb5_util.c index 4b13fa1..c84d978 100644 --- a/utils/gssd/krb5_util.c +++ b/utils/gssd/krb5_util.c @@ -129,6 +129,8 @@ /* Global list of principals/cache file names for machine credentials */ struct gssd_k5_kt_princ *gssd_k5_kt_princ_list = NULL; +int limit_to_legacy_enctypes = 0; + /*==========================*/ /*=== Internal routines ===*/ /*==========================*/ @@ -1342,7 +1344,7 @@ limit_krb5_enctypes(struct rpc_gss_sec *sec) * If we failed for any reason to produce global * list of supported enctypes, use local default here. */ - if (krb5_enctypes == NULL) + if (krb5_enctypes == NULL || limit_to_legacy_enctypes) maj_stat = gss_set_allowable_enctypes(&min_stat, credh, &krb5oid, num_enctypes, enctypes); else diff --git a/utils/gssd/krb5_util.h b/utils/gssd/krb5_util.h index b42b91e..ddf00ca 100644 --- a/utils/gssd/krb5_util.h +++ b/utils/gssd/krb5_util.h @@ -38,6 +38,7 @@ void gssd_k5_get_default_realm(char **def_realm); #ifdef HAVE_SET_ALLOWABLE_ENCTYPES int limit_krb5_enctypes(struct rpc_gss_sec *sec); #endif +extern int limit_to_legacy_enctypes; /* * Hide away some of the MIT vs. Heimdal differences -- 1.7.3.4 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-04-12 15:49 ` Michael Weiser @ 2012-04-12 16:02 ` Steve Dickson 2012-04-13 12:34 ` Michael Weiser 2012-04-16 10:51 ` Steve Dickson 0 siblings, 2 replies; 17+ messages in thread From: Steve Dickson @ 2012-04-12 16:02 UTC (permalink / raw) To: Michael Weiser; +Cc: linux-nfs On 04/12/2012 11:49 AM, Michael Weiser wrote: > Hi Steve, > > On Thu, Apr 12, 2012 at 10:43:20AM -0400, Steve Dickson wrote: > >>> How do I go about getting this committed? >> My bad... I'm looking into this now.... > > Thanks for getting back to me. > >>>> I just noticed that while the code bits are optional based on >>>> HAVE_SET_ALLOWABLE_ENCTYPES, the man page part isn't. I've got no idea, >>>> how to go about that. >> I'm think we should remove all those defines and have the code enabled >> by default. The main reason is defines like that just clutter up the >> code, plus there would be a needed for another configuration flag >> which I think is a bit over kill... > > Here it is. The whole HAVE_SET_ALLOWABLE_ENCTYPES logic is still in place > but my code now ignores it. So with a GSSAPI implementation that doesn't > support it, the -l switch will be accepted by gssd but silently do > nothing. Well after further review.... it appears remove moving those defines would have a negative impact on backwards compatibility with older Kerberos libraries. So what I'm thinking of doing is error out if an admin tries to use the -l flag with incompatible Kerberos libraries. I also made a note in the man page. So how about something like this: Author: Michael Weiser <weiser@science-computing.de> Date: Thu Apr 12 11:50:03 2012 -0400 Add -l option to gssd to force legacy behaviour Implement a new option -l to force gssd to ignore its kernel's crypto capabilities and use just the Single DES legacy encryption types to be compatible with old servers. This is only relevant if those servers have strong keys in their keytab. Signed-off-by: Steve Dickson <steved@redhat.com> diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c index d53795e..7825255 100644 --- a/utils/gssd/gssd.c +++ b/utils/gssd/gssd.c @@ -85,7 +85,7 @@ sig_hup(int signal) static void usage(char *progname) { - fprintf(stderr, "usage: %s [-f] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n", + fprintf(stderr, "usage: %s [-f] [-l] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n", progname); exit(1); } @@ -102,7 +102,7 @@ main(int argc, char *argv[]) char *progname; memset(ccachesearch, 0, sizeof(ccachesearch)); - while ((opt = getopt(argc, argv, "fvrmnMp:k:d:t:R:")) != -1) { + while ((opt = getopt(argc, argv, "fvrlmnMp:k:d:t:R")) != -1) { switch (opt) { case 'f': fg = 1; @@ -143,6 +143,13 @@ main(int argc, char *argv[]) case 'R': preferred_realm = strdup(optarg); break; + case 'l': +#ifdef HAVE_SET_ALLOWABLE_ENCTYPES + limit_to_legacy_enctypes = 1; +#else + errx(1, "Setting encryption type not support by Kerberos libraries."); +#endif + break; default: usage(argv[0]); break; diff --git a/utils/gssd/gssd.man b/utils/gssd/gssd.man index 073379d..d8138fa 100644 --- a/utils/gssd/gssd.man +++ b/utils/gssd/gssd.man @@ -6,7 +6,7 @@ .SH NAME rpc.gssd \- rpcsec_gss daemon .SH SYNOPSIS -.B "rpc.gssd [-f] [-n] [-k keytab] [-p pipefsdir] [-v] [-r] [-d ccachedir]" +.B "rpc.gssd [-f] [-n] [-k keytab] [-l] [-p pipefsdir] [-v] [-r] [-d ccachedir]" .SH DESCRIPTION The rpcsec_gss protocol gives a means of using the gss-api generic security api to provide security for protocols using rpc (in particular, nfs). Before @@ -70,6 +70,30 @@ for "machine credentials" is now: If this search order does not use the correct key then provide a keytab file that contains only correct keys. .TP +.B -l +Tells +.B rpc.gssd +to limit session keys to Single DES even if the kernel supports stronger +encryption types. Service ticket encryption is still governed by what +the KDC believes the target server supports. This way the client can +access a server that has strong keys in its keytab for ticket decryption +but whose kernel only supports Single DES. +.IP +The alternative is to put only Single DES keys in the server's keytab +and limit encryption types for its principal to Single DES on the KDC +which will cause service tickets for this server to be encrypted using +only Single DES and (as a side-effect) contain only Single DES session +keys. +.IP +This legacy behaviour is only required for older servers +(pre nfs-utils-1.2.4). If the server has a recent kernel, Kerberos +implementation and nfs-utils it will work just fine with stronger +encryption. +.IP +.B Note: +This option is only available with Kerberos libraries that +support setable encryption types. +.TP .B -p path Tells .B rpc.gssd diff --git a/utils/gssd/krb5_util.c b/utils/gssd/krb5_util.c index 4b13fa1..887d118 100644 --- a/utils/gssd/krb5_util.c +++ b/utils/gssd/krb5_util.c @@ -129,6 +129,10 @@ /* Global list of principals/cache file names for machine credentials */ struct gssd_k5_kt_princ *gssd_k5_kt_princ_list = NULL; +#ifdef HAVE_SET_ALLOWABLE_ENCTYPES +int limit_to_legacy_enctypes = 0; +#endif + /*==========================*/ /*=== Internal routines ===*/ /*==========================*/ @@ -1342,7 +1346,7 @@ limit_krb5_enctypes(struct rpc_gss_sec *sec) * If we failed for any reason to produce global * list of supported enctypes, use local default here. */ - if (krb5_enctypes == NULL) + if (krb5_enctypes == NULL || limit_to_legacy_enctypes) maj_stat = gss_set_allowable_enctypes(&min_stat, credh, &krb5oid, num_enctypes, enctypes); else diff --git a/utils/gssd/krb5_util.h b/utils/gssd/krb5_util.h index b42b91e..cd6e107 100644 --- a/utils/gssd/krb5_util.h +++ b/utils/gssd/krb5_util.h @@ -36,6 +36,7 @@ char *gssd_k5_err_msg(krb5_context context, krb5_error_code code); void gssd_k5_get_default_realm(char **def_realm); #ifdef HAVE_SET_ALLOWABLE_ENCTYPES +extern int limit_to_legacy_enctypes; int limit_krb5_enctypes(struct rpc_gss_sec *sec); #endif If this seems reasonable, would you mind giving it a test run to ensure I have not broken anything? tia.. steved. ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-04-12 16:02 ` Steve Dickson @ 2012-04-13 12:34 ` Michael Weiser 2012-04-16 10:51 ` Steve Dickson 1 sibling, 0 replies; 17+ messages in thread From: Michael Weiser @ 2012-04-13 12:34 UTC (permalink / raw) To: Steve Dickson; +Cc: linux-nfs Hi Steve, On Thu, Apr 12, 2012 at 12:02:19PM -0400, Steve Dickson wrote: > > Here it is. The whole HAVE_SET_ALLOWABLE_ENCTYPES logic is still in place > > but my code now ignores it. So with a GSSAPI implementation that doesn't > > support it, the -l switch will be accepted by gssd but silently do > > nothing. > Well after further review.... it appears remove moving those defines would > have a negative impact on backwards compatibility with older Kerberos > libraries. > So what I'm thinking of doing is error out if an admin tries to use the > -l flag with incompatible Kerberos libraries. I also made a note in > the man page. So how about something like this: No arguments from me. Seems a great solution. > If this seems reasonable, would you mind giving it a test run to > ensure I have not broken anything? tia.. I gave it a spin on my RHEL6 VM and everything still works. Compiling with HAVE_SET_ALLOWABLE_ENCTYPES undefined produces a gssd that bails as intended: [root@rhel6 gssd]# ./gssd -vvv -f -l gssd: Setting encryption type not support by Kerberos libraries. Thanks, -- Michael Weiser science + computing ag Senior Systems Engineer Geschaeftsstelle Duesseldorf Martinstrasse 47-55, Haus A phone: +49 211 302 708 32 D-40223 Duesseldorf fax: +49 211 302 708 50 www.science-computing.de -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server 2012-04-12 16:02 ` Steve Dickson 2012-04-13 12:34 ` Michael Weiser @ 2012-04-16 10:51 ` Steve Dickson 1 sibling, 0 replies; 17+ messages in thread From: Steve Dickson @ 2012-04-16 10:51 UTC (permalink / raw) To: Steve Dickson; +Cc: Michael Weiser, linux-nfs On 04/12/2012 12:02 PM, Steve Dickson wrote: > > > On 04/12/2012 11:49 AM, Michael Weiser wrote: >> Hi Steve, >> >> On Thu, Apr 12, 2012 at 10:43:20AM -0400, Steve Dickson wrote: >> >>>> How do I go about getting this committed? >>> My bad... I'm looking into this now.... >> >> Thanks for getting back to me. >> >>>>> I just noticed that while the code bits are optional based on >>>>> HAVE_SET_ALLOWABLE_ENCTYPES, the man page part isn't. I've got no idea, >>>>> how to go about that. >>> I'm think we should remove all those defines and have the code enabled >>> by default. The main reason is defines like that just clutter up the >>> code, plus there would be a needed for another configuration flag >>> which I think is a bit over kill... >> >> Here it is. The whole HAVE_SET_ALLOWABLE_ENCTYPES logic is still in place >> but my code now ignores it. So with a GSSAPI implementation that doesn't >> support it, the -l switch will be accepted by gssd but silently do >> nothing. > Well after further review.... it appears remove moving those defines would > have a negative impact on backwards compatibility with older Kerberos > libraries. > > So what I'm thinking of doing is error out if an admin tries to use the > -l flag with incompatible Kerberos libraries. I also made a note in > the man page. So how about something like this: > > > Author: Michael Weiser <weiser@science-computing.de> > Date: Thu Apr 12 11:50:03 2012 -0400 > > Add -l option to gssd to force legacy behaviour > > Implement a new option -l to force gssd to ignore its kernel's crypto > capabilities and use just the Single DES legacy encryption types to be > compatible with old servers. This is only relevant if those servers have > strong keys in their keytab. > > Signed-off-by: Steve Dickson <steved@redhat.com> Committed... steved. > > diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c > index d53795e..7825255 100644 > --- a/utils/gssd/gssd.c > +++ b/utils/gssd/gssd.c > @@ -85,7 +85,7 @@ sig_hup(int signal) > static void > usage(char *progname) > { > - fprintf(stderr, "usage: %s [-f] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n", > + fprintf(stderr, "usage: %s [-f] [-l] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n", > progname); > exit(1); > } > @@ -102,7 +102,7 @@ main(int argc, char *argv[]) > char *progname; > > memset(ccachesearch, 0, sizeof(ccachesearch)); > - while ((opt = getopt(argc, argv, "fvrmnMp:k:d:t:R:")) != -1) { > + while ((opt = getopt(argc, argv, "fvrlmnMp:k:d:t:R")) != -1) { > switch (opt) { > case 'f': > fg = 1; > @@ -143,6 +143,13 @@ main(int argc, char *argv[]) > case 'R': > preferred_realm = strdup(optarg); > break; > + case 'l': > +#ifdef HAVE_SET_ALLOWABLE_ENCTYPES > + limit_to_legacy_enctypes = 1; > +#else > + errx(1, "Setting encryption type not support by Kerberos libraries."); > +#endif > + break; > default: > usage(argv[0]); > break; > diff --git a/utils/gssd/gssd.man b/utils/gssd/gssd.man > index 073379d..d8138fa 100644 > --- a/utils/gssd/gssd.man > +++ b/utils/gssd/gssd.man > @@ -6,7 +6,7 @@ > .SH NAME > rpc.gssd \- rpcsec_gss daemon > .SH SYNOPSIS > -.B "rpc.gssd [-f] [-n] [-k keytab] [-p pipefsdir] [-v] [-r] [-d ccachedir]" > +.B "rpc.gssd [-f] [-n] [-k keytab] [-l] [-p pipefsdir] [-v] [-r] [-d ccachedir]" > .SH DESCRIPTION > The rpcsec_gss protocol gives a means of using the gss-api generic security > api to provide security for protocols using rpc (in particular, nfs). Before > @@ -70,6 +70,30 @@ for "machine credentials" is now: > If this search order does not use the correct key then provide a > keytab file that contains only correct keys. > .TP > +.B -l > +Tells > +.B rpc.gssd > +to limit session keys to Single DES even if the kernel supports stronger > +encryption types. Service ticket encryption is still governed by what > +the KDC believes the target server supports. This way the client can > +access a server that has strong keys in its keytab for ticket decryption > +but whose kernel only supports Single DES. > +.IP > +The alternative is to put only Single DES keys in the server's keytab > +and limit encryption types for its principal to Single DES on the KDC > +which will cause service tickets for this server to be encrypted using > +only Single DES and (as a side-effect) contain only Single DES session > +keys. > +.IP > +This legacy behaviour is only required for older servers > +(pre nfs-utils-1.2.4). If the server has a recent kernel, Kerberos > +implementation and nfs-utils it will work just fine with stronger > +encryption. > +.IP > +.B Note: > +This option is only available with Kerberos libraries that > +support setable encryption types. > +.TP > .B -p path > Tells > .B rpc.gssd > diff --git a/utils/gssd/krb5_util.c b/utils/gssd/krb5_util.c > index 4b13fa1..887d118 100644 > --- a/utils/gssd/krb5_util.c > +++ b/utils/gssd/krb5_util.c > @@ -129,6 +129,10 @@ > /* Global list of principals/cache file names for machine credentials */ > struct gssd_k5_kt_princ *gssd_k5_kt_princ_list = NULL; > > +#ifdef HAVE_SET_ALLOWABLE_ENCTYPES > +int limit_to_legacy_enctypes = 0; > +#endif > + > /*==========================*/ > /*=== Internal routines ===*/ > /*==========================*/ > @@ -1342,7 +1346,7 @@ limit_krb5_enctypes(struct rpc_gss_sec *sec) > * If we failed for any reason to produce global > * list of supported enctypes, use local default here. > */ > - if (krb5_enctypes == NULL) > + if (krb5_enctypes == NULL || limit_to_legacy_enctypes) > maj_stat = gss_set_allowable_enctypes(&min_stat, credh, > &krb5oid, num_enctypes, enctypes); > else > diff --git a/utils/gssd/krb5_util.h b/utils/gssd/krb5_util.h > index b42b91e..cd6e107 100644 > --- a/utils/gssd/krb5_util.h > +++ b/utils/gssd/krb5_util.h > @@ -36,6 +36,7 @@ char *gssd_k5_err_msg(krb5_context context, krb5_error_code code); > void gssd_k5_get_default_realm(char **def_realm); > > #ifdef HAVE_SET_ALLOWABLE_ENCTYPES > +extern int limit_to_legacy_enctypes; > int limit_krb5_enctypes(struct rpc_gss_sec *sec); > #endif > > > If this seems reasonable, would you mind giving it a test run to > ensure I have not broken anything? tia.. > > steved. > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2012-04-16 10:51 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-12 20:02 NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server Michael Weiser 2012-03-12 20:24 ` Jim Rees 2012-03-12 21:10 ` Kevin Coffman 2012-03-12 21:57 ` Michael Weiser 2012-03-13 13:51 ` Kevin Coffman 2012-03-13 14:42 ` Michael Weiser 2012-03-13 18:53 ` Kevin Coffman 2012-03-14 13:48 ` Michael Weiser 2012-03-19 13:00 ` Michael Weiser 2012-03-20 11:27 ` Steve Dickson 2012-03-20 17:44 ` Michael Weiser 2012-03-29 14:02 ` Michael Weiser 2012-04-12 14:43 ` Steve Dickson 2012-04-12 15:49 ` Michael Weiser 2012-04-12 16:02 ` Steve Dickson 2012-04-13 12:34 ` Michael Weiser 2012-04-16 10:51 ` Steve Dickson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.