From: Peter Staubach (staubach@nyday.eng.sun.com)
Date: 05/18/99-01:59:53 PM Z
Date: Tue, 18 May 1999 11:59:53 -0700 (PDT) From: Peter Staubach <staubach@nyday.eng.sun.com> Message-Id: <199905181859.LAA35548@nyday.eng.sun.com> Subject: Re: New file handle section (hard links) > > > > > > > The option of splitting the handle into two sections, only one of which > > > > would be assumed to uniquely specify a filesystem object is certainly > > > > a resonable approach in that it would allow export information to > > > > be placed in the handle but allow the client to very easily determine > > > > if two handles denoted the same object. I think Uresh proposed this. > > > > Although this option is highly non-traditional, I don't see what's > > > > wrong with it. (No doubt someone is going to tell me). > > > > > > Splitting the fh in that way makes it somewhat easier for the client to > > > circumvent security controls. > > > > > > Say /export/a is exported read-only, /export/b is exported read-write. I get a > > > file handle for directory /export/a/c, and a file handle for directory > > > /export/b/d. I replace the export info of c's fh with the export info of d's > > > fh. Voila, write access to /export/a. This is doable with opaque file > > > handles, but the client needs to understand the composition of the fh. > > > Once the protocol make de-composition easy, there will no doubt be > > > lots of little programs written to exploit it. > > > > > > > This assumes a dysfunctional server. No NFS server should bypass export > > checks simply because you have a valid file handle. Export permissions can > > change any time and the client may have cached the file handle for a long > > time. Second, replacing one part of the fh with the corresponding part from > > another file should not necessarily give you a valid handle. The "private" > > part of the handle is truly opaque, and can easily contain sufficient > > information to validate the handle. > > > > Moreover, there are millions of ways in which a vile client can circumvent > > the security mechanisms of NFS (remember NFS stands for Not Secure :-)). Of > > course, we should not add new holes, but this one is easily prevented by > > server implementation. > > Please explain how you've implemented protection against the attack > I've described. > Ahh... I see. The client is properly authenticated as far as the export for /export/b is concerned, so it is granted access. The format of the file handle for various implementations is pretty well known already. We, Sun, certainly haven't taken any steps to hide the contents and format of the file handle. (It is documented in a system header file...) So, does the file handle need to contain a checksum or some such which is only calculable by the server? ps
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:05 AM Z CST