[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-nfs-discuss
Subject:    Re: [nfs-discuss] [Labeled-nfs] New MAC label support Internet
From:       "David P. Quigley" <dpquigl () tycho ! nsa ! gov>
Date:       2009-02-12 19:45:21
Message-ID: 1234467921.2929.143.camel () moss-terrapins ! epoch ! ncsc ! mil
[Download RAW message or body]

On Thu, 2009-02-12 at 12:07 +1100, James Morris wrote:
> On Wed, 11 Feb 2009, David P. Quigley wrote:
> 
> > sort of open file handle revocation support. In the past people have
> > suggested building the client's idea of the label into either the
> > stateid or some other form of cookie that can be verified by the server.
> > We explored doing this in the form of an NFSv4 op and while that worked
> > we are trying to shy away from adding new operations if we can help it.
> 
> What's wrong with adding new operations?
> 
> 
> - James


For the sake of discussion I'll talk about the previous work we did on
this topic. In the presentation I gave at IETF 71 we had a new NFSv4
operation called OP_PUTCLIENTLABEL. The idea of this was it was to work
like a PUTFH call in that you would push some state to the server which
would be used to evaluate all portions of the compound operation after
it. The idea was that the client would say that it believes the file is
TOP SECRET by issuing a PUTCLIENTLABEL at the beginning of the compound
op with the label TOP SECRET as the value. When the server evaluated the
parts of the compound operation that used a file handle it would check
if the label for that FH matched the one asserted by the client in the
PUTCLIENTLABEL operation. If they didn't match, the server returned an
ESTALE error and hopefully the client would refetch the file handle. At
the time Linux didn't have good support for recovering from an ESTALE
but since then I believe that support was fixed.

Someone in the audience brought up that we possibly had the
PUTCLIENTLABEL op in the wrong place because it wasn't being protected
by one of the replay attack mechanisms. This would have been easy to fix
but some people seemed skeptical to doing this as a new operation (we
had a total of two or three that were being proposed). So we went back
and looked for another way to do it. James had suggested building it
into the stateid and Nico has suggested to use volatile FHs for it. 

When I gave a followup presentation at IETF 72 I mentioned that we had
removed the operations. After the presentation I believe Mike Eisler
mentioned that it was good that we avoided adding new operations. He
said that they were trying to make future revisions to NFSv4 (4.2 and
higher) move more quickly through the process since they would be
smaller revisions. We hoped making the required protocol changes smaller
would help move things along more quickly.

I'd like to hear more from Nico on how we can use volatile FHs to solve
this problem. The document still needs more work to take care of things
like this but I was hoping this revision could get the discussion
rolling so other people would provide input into the design. It seems
that it is getting attention now.

Dave

_______________________________________________
nfs-discuss mailing list
nfs-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]