Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review

[Nico Williams <[e-mail]>]

On Mon, Aug 04, 2014 at 12:00:16PM -0400, J. Bruce Fields wrote:
> On Fri, Aug 01, 2014 at 05:15:36PM -0500, Nico Williams wrote:
> > It was always my intention that traditional (read: multi-user
> > shared-cache) NFS client implementations would just always use
> > "multi-principal" contexts when doing any RPCs on a user's behalf.
> > 
> > That is, addressing the "user can impersonate the server to the client"
> > problem was always my first and foremost goal with this protocol, though
> > I didn't always say so explicitly (since at the time the attack was not
> > well-known, I didn't want to publicize it).
> 
> Oh, that's really helpful to know.

Yeah :(  I mentioned it several times at meetings.  The cat has been
out of the bag for a long time as to the vulnerability for shared-cache
clients, so we might as well state this motivation clearly.

Note that such clients really need server support for this.  The only
other alternative for clients is to not share the NFSv4 cache _at all_,
but this is very difficult for some client architectures.

It's trivial for clients that can do Plan9-style namespace management,
though even then it's critical that when the system does an exec() it
doesn't trust any set-uid/gid bits from an executable's vnode.  I.e.,
it's critical that the cache not be shared even with the privilege
management parts of the system.

Even where cache non-sharing is trivial, cache sharing has significant
resource usage benefits in multi-user systems, therefore it is or can be
highly desirable.  It's worth noting that multi-user systems are
becoming less common, but multiple levels of privilege for a single
user's processes is still likely to be a common situation.

> It'd be great if we could get a paragraph into the draft explaining
> this.  (And also the server-to-server copy stuff, and any other example
> uses.)  It's easier to understand with the motivations.

Yes.

Nico
--