Date: Wed, 05 Sep 2012 14:58:25 +0100 From: =?UTF-8?B?QXR0aWxhIEJvZ8Ohcg==?= <attila.bogar@linguamatics.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-fs@FreeBSD.org Subject: Re: NFS: rpcsec_gss with Linux clients Message-ID: <50475A81.2040105@linguamatics.com> In-Reply-To: <817398955.1415204.1346543870350.JavaMail.root@erie.cs.uoguelph.ca> References: <817398955.1415204.1346543870350.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Rick, On 02/09/12 00:57, Rick Macklem wrote: > This certainly sounds bogus. I can see an argument for 2 TCP > connections for trunking, but since a security context should only be > destroyed when the client is done with it, doing a DESTROY doesn't > make sense? (There is something in the RPC header called a "handle". > It identifies the security context, and it would be nice to check the > wireshark trace to see if it the same as the one being used on the > other connection?) TCP0: -> Linux NFS AUTH_NULL TCP0: <- FreeBSD responds TCP1: -> Linux sends RPCSEC_GSS_INIT TCP1: <- FreeBSD responds by establishing GSS Context (it's a 16 byte token) TCP1: -> Linux sends RPCSEC_GSS_DESTROY using the received 16 byte token TCP0: -> Linux sends NFS:PUTROOTFS|GETATTR using the same 16 byte received gss context token >> I don't quite know why, but during the destroy within the the >> svc_rpc_gss_validate() gss_verify_mic() returns maj_stat = >> GSS_S_DEFECTIVE_TOKEN, no matter what heimdal version I use. >> > That would indicate the encrypted checksum isn't correct. It > might be using an algorithm only supported by the newer RPCSEC_GSS_V3? It's RPC version 2, GSS version: 1 > For DESTROY when it will fail, I'm not sure if marking the > context stale makes sense. (I can see an argument for and against > doing this.) If you "know" other people's context by snooping the wire, you can invalidate their client entry on the nfs server by sending a corrupted (corrupted, because you don't know their keytab) RPCSEC_GSS_DESTROY message. I suspect an attacker can force the kerberos clients to re-establish the security context again and again. I'm not sure this statistically can lead to any advantage breaking the keys, kerberos experts may answer this. > I've attached a small patch with disables setting client->cl_state > to CLIENT_STALE for this case, which you could try, to see if it > helps? I'll look at it. > I'd suggest contacting the Linux folks first and see if they are > willing to look at the wireshark trace or know of an issue/fix, > because it really sounds like a Linux client issue. > Waiting 4 minutes instead of 5 shouldn't have any real effect, > although it might avoid the problem for your case w.r.t. timing. This is an intuition to test a fix for another bug. I noticed, that when my users need long file access, they get a permission denied error at the gss key change time, which is very annoying after the program having run for multiple hours. > This time is usually the TGT lifetime (12->24hrs), so subtracting > 12 sec from it doesn't really make any sense. (I will note that > the calculation of cred_lifetime for the GSS_C_INDEFINITE case > looks incorrect, since time_uptime gets added twice, but I doubt > that's relevant to your problem, since it is set to more than 24hrs.) The rpcsec timestamp is valid, so this passes this layer. But when it's actually handled by the NFS layer, how can this permission denied come into the picture? Is there another GSS timestamp check on the upper level? > /* > * Fill in cred details in the rawcred structure. > @@ -990,7 +995,7 @@ > gss_buffer_desc rpcbuf, checksum; > OM_uint32 maj_stat, min_stat; > gss_qop_t qop_state; > - int32_t rpchdr[128 / sizeof(int32_t)]; > + int32_t rpchdr[2048 / sizeof(int32_t)]; > int32_t *buf; Note, that I changed the buffer from 128 bytes to 2048 bytes. This is as per PR 162009, which is also hanging around. I think checking the code for the RPC 128 byte buffers would be nice for security and other reasons. I'm going to send an email to the linux-nfs@ to find out what's going on this area - maybe this has been already fixed, as I use some old EL6 and Ubuntu 12.04 flavours. However dropping the sec context even with failed kerberos ticket seems like a FreeBSD bug. Kind regards, Attila -- Attila Bogár Systems Administrator Linguamatics - Cambridge, UK http://www.linguamatics.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50475A81.2040105>