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

Nico Williams <nico@cryptonector.com> Mon, 05 June 2017 16:53 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B8F129B56; Mon, 5 Jun 2017 09:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.8
X-Spam-Level:
X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VERQhr0hHiO; Mon, 5 Jun 2017 09:53:01 -0700 (PDT)
Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DF7129B73; Mon, 5 Jun 2017 09:53:01 -0700 (PDT)
Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id B09ABC002827; Mon, 5 Jun 2017 09:53:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=MiN1f3hgq1H8Sq JjLpPrwTBcyLs=; b=t5VKm+nC4dZA6rXkbf1j42NcUt5tA0vdmyQVjQa9MTsYlJ QGKIS8+RC9hXi1bEV4oQUKA7vQ606n9g808naaPxSnRI8JKdtZ3VFXKD9MyWb4Vm Rfi9+JL2DAkQlv1jFbGkRfFXQcYn2piPF8rp/E9+QYkx4cJStvxicubUg6qVE=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 71039C002821; Mon, 5 Jun 2017 09:52:59 -0700 (PDT)
Date: Mon, 05 Jun 2017 11:52:55 -0500
From: Nico Williams <nico@cryptonector.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: David Noveck <davenoveck@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, NFSv4 <nfsv4@ietf.org>
Message-ID: <20170605165254.GE2903@localhost>
References: <CAMm+Lwh+E+BsATQmmX6ccJou-sz1XNtFHxQZikohYCeT0qkfdQ@mail.gmail.com> <CAKKJt-fsJ1UinNiW2LitxVQT4M1YqnFF+1cygU132=bQNgiUnA@mail.gmail.com> <CADaq8jd+6gN2H0QWC+dM-e3pb1gUJKLE7=8PPpprGGKBQZhueg@mail.gmail.com> <CACsn0cnd0L2o2Db6OA1Uvp-C+geA+Ju-7E8Yo=OKS1V3P4G8sA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CACsn0cnd0L2o2Db6OA1Uvp-C+geA+Ju-7E8Yo=OKS1V3P4G8sA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/l8-nj1WHx1K_WrviM4ff2KRjWnQ>
Subject: Re: [secdir] [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jun 2017 16:53:03 -0000

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 <davenoveck@gmail.com> 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
--