Re: [secdir] [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03

[David Noveck <[e-mail]>]

> A more complete analysis of RPCSEC_GSS should really not be
> done in the context of this I-D.

I agree that it should not, but it is not clear exactly what is being asked
for to
get this document into the RFC editing process.  Unlike xattrs, this
document
actually has been approved.  The state is listed as "Approved-announcement
to
be sent::Point Raised - writeup needed" so we know it has been approved but
are unclear about why this has not been announced, what exactly the point
raised
might be and how the issue/point is to be resolved.

I think the authors are entitled to a clearer treatment of these matters.

On Mon, Jun 5, 2017 at 12:52 PM, Nico Williams <[e-mail]>
wrote:

>
> I find this much debate about a rather trivial extension that helps
> NFSv4 meet the Unix security model... a bit surprising.  But onward, I
> shall answer your questions.
>
> As you'll see, the umask extension strictly *improves* security.
>
> On Wed, May 31, 2017 at 08:59:30PM -0700, Watson Ladd wrote:
> > On Wed, May 31, 2017 at 6:23 AM, David Noveck <[e-mail]>
> wrote:
> > > Phillip Hallam-Baker wrote
> > >> They are not so much a security plan as a collection of random
> thoughts
> > >> jotted down
> > >> in haphazard fashion.
> > >
> > > This is fair criticism.  I've looked through the Security
> Considerations
> > > sections of RFCs 3530, 7530, and 5661 and the differences are minor.
>  None
> > > of these sections were written to provide a security plan, but tried to
> > > describe, somewhat inelegantly, the evolution of NFS from its origins
> in a
> > > LAN environment towards NFSv4 which attempted to provide some
> reasonable
> > > security features.  Any security needs were provided by RPCSECGSS, and
> not
> > > by the protocol itself.
> > >
> > >> There is clearly no coherent model of what NFS security should
> > >> achieve, what the threats are, what controls are deployed to
> > >> control them
> > >
> > > An alternative would have been to define an entirely new protocol with
> a
> > > real security plan covering these matters, but that wasn't the goal
> then.
> > > If it had been, we would probably have a much more secure protocol that
> > > nobody would deploy.  What happened was that NFSv4 was defined
> requiring
> > > implementation, but not use, of RPCSECGSS.  Even today, many NFSv4
> > > deployments use AUTH_SYS and very few which use RPCSECGSS, use
> integrity or
> > > privacy, because of performance issues.  Security is provided by use of
> > > physically isolated networks or VPNs.   That was considered adequate
> when
> > > RFCs 3530, 5661, and 7530 were written and approved.
> >
> > How does this address the sorts of problems associated with the NFS
> > permissions model? Furthermore, this candy bar network (crunchy shell
> > with gooey inside) is a real liability. It would be nice if we could
> > make it easier to move away from.
>
> So... the idea is that:
>
>  - the client establishes a "security context" that authenticates the
>    user as some principal (using Kerberos, PKIX, SCRAM, whatever)
>
>  - the server then establishes the client's UIDs/GIDs/SIDs/whatever is
>    appropriate (if anything) on the server side -- let's call this the
>    "authorization context"
>
>  - subsequent RPCs for that user are made with that security context,
>    thus identifying the user to the server
>
> The server then authorizes calls as follows:
>
>  - validates the request (see RPCSEC_GSS)
>
>  - maps the security context ID to the authorization context for that
>    security context
>
>  - evaluates whatever ACLs or mode bits are associated with any files or
>    directories (or other objects) the user wishes to access, and grants
>    or denies access accordingly.
>
> Now, mode bits and umask are a bit odd when used together with proper
> access control lists.  However, there are ways to make them meaningful.
>
> For example, if I chmod 0600 a file then all access bits will be removed
> a) for all ACL entries (ACEs) that refer to non-owner users, b) for all
> groups, c) for the "everyone" entry.  Increasing access, e.g., with
> chmod 0664, is trickier, but still, there's a way to make it meaningful.
>
> This is really important: it *is* possible to make mode bit changes
> meaningful with ACLs.
>
> A umask basically says "determine the ACL of new files/directories by
> first adding the inheritable ACEs as usual, then applying the umask to
> decrease or increase access as by a chmod, and do all of this
> atomically".
>
> The atomicity is the important part, because otherwise a client might
> create a file that initially starts out as having a broad (inherited!)
> ACL, and then decrease access via a second operation (possibly in the
> same RPC, but RPCs are not atomic), thus creating a race condition when
> trying to create files with more restrictive ACLs.
>
> Clearly, the umask very much improves security.  It is rather shocking
> that NFSv4 didn't have it to begin with.
>
> We figured out the correct way to a) construct apparent mode bits from
> ACLs, and b) apply mode bits changes to ACLs, years ago after many
> dissatisfying attempts.  I don't think that is at all codified in any
> RFC (but I don't follow NFSv4 that closely, so I may be wrong).  Perhaps
> it should be, even though experimenting with various different
> algorithms was made possible by... not specifying it in the first place
> -- the state of the art here seems mature.
>
> > > If it is appropriate to move the goal posts here, based on current
> needs, we
> > > have to understand exactly what is being asked for, in order to see if
> > > remediation is possible while maintaining continuity with the existing
> NFSv4
> > > protocol and implementations.  Some possibilities:
> > >
> > > A clear security plan which defines the threats that NFSv4 addresses
> and is
> > > clear about those it does not address (and so have to addressed by
> other
> > > means).
> > > A security plan plan defining the threats that NFSv4 should address,
> how
> > > some of those are addressed by various NFSv4 minor versions, and
> others will
> > > be by extensions to NFSv4.2 or later minor versions.
> >
> > I prefer the second, but it might never happen. The first is at least
> > useful (when combined with what NFSv4 could address as shown by other
> > systems of similar kind)
>
> I will admit to not knowing how comprehensively NFSv4's various base
> RFCs cover the NFSv4 security model -- they are enormous RFCs.  Some
> details are very much left to implementors, mainly how user/group IDs
> are represented on disk, how the "authorization context" for any one
> user is established, and how the implementation interfaces with other
> protocols such as SMB or local POSIX access.  Leaving those details to
> implementors is purposeful.
>
> I've covered authentication and authorization (above).
>
> I can also speak about the transport security model.  Spoilers: it's not
> that good, and the first attempt to make it significantly better via
> IPsec failed due to lack of implementation of RFC5660.  But it's not
> exactly broken.
>
> NFSv4's transport security protocol is woefully inefficient for
> multi-user clients, but those have gone the way of the dodo.  It's
> inefficient too in terms of ability to leave crypto to HW -- only IPsec
> w/ RFC5660 can help here.  And even for single-user clients, it's
> inefficient in that RPCSEC_GSS pre-dates AEAD functionality in GSS, so
> it uses two GSS operations per-request (and two per-response) where one
> should do -- i.e., it has higher overhead than it needs to.
>
> The non-use of IPsec or TLS to protect the confidentiality (and
> integrity) of all of the flows between an NFSv4 client and server means
> that some traffic analysis can be done, identifying users identified to
> eavesdroppers (depending on which GSS mechanism is used).  A more
> complete analysis of RPCSEC_GSS should really not be done in the context
> of this I-D.
>
> Nico
> --
>