Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-xattrs-05: (with DISCUSS)

["Marc Eshel" <[e-mail]>]

We had a lot of discussions in the WG about the security implications and 
we decided to stay a way of defining different types of xattr. This is 
user only xattr for the applications to use and it should be handled as an 
extension to the data in the file without any meaning for the protocol. If 
it is not clear enough we can fix the text and add a warning. 
Marc.



From:   Nico Williams <[e-mail]>
To:     Spencer Dawkins at IETF <[e-mail]>
Cc:     Eric Rescorla <[e-mail]>, [e-mail], 
The IESG <[e-mail]>, NFSv4 <[e-mail]>, [e-mail]
Date:   05/25/2017 08:30 AM
Subject:        Re: [nfsv4] Eric Rescorla's Discuss on 
draft-ietf-nfsv4-xattrs-05: (with DISCUSS)



On Thu, May 25, 2017 at 10:35:53AM -0400, Spencer Dawkins at IETF wrote:
> Dear -xattrs- folk,
> 
> We did chat about this Discuss on the call, and Eric said (in the jabber
> room) that if the issue he raised is accurate, at a minimum, the 
document
> needs to provide a warning about the exposure, in order to clear the
> Discuss.

No, i think it has to provide, at a minimum, a MUST NOT (see below).

The alternative is to add proper support for system xattrs.  I discuss
both below.

> Actual technical solutions that mitigate the exposure are, of course,
> appreciated, if it's possible to provide a solution.

A better way to deal with this would be to have a way to flag some
xattrs as being system xattrs, and more importantly, to indicate whether
the client and server support whatever the system xattr's semantics are.

If a client doesn't support some system xattr, the server might provide
more limited access to the file that has that xattr.  If a server
doesn't support some system xattr, the client might fail the operation
to set it.  It all depends on the particular system xattr's semantics.

E.g., a system xattr denoting append-only or read-only can be enforced
by the server, but setting it when the server doesn't support it means
that other clients might not enforce it either.

An xattr that denotes privileges to be gained on exec (a la set-uid),
probably requires extra permission to set -- if the server doesn't know
this, then other clients must not grant those extra privileges on exec!

Alternatively, you could just say that at this time NFSv4 simply does
not support system xattrs, and that no xattrs with names in a system
namespace must be trusted by clients.  This is where the MUST NOT comes
in: the spec would say "clients MUST NOT accord special system semantics
to xattrs" (with some wordsmithing around "system" xattrs).  Then you
could add the flagging feature later.  But you'll have to distinguish
system xattrs set pre- and post-addition of the flagging feature.

Nico
--