Re: [nfsv4] Review of draft-ief-nfsv4-integrity-measurement-04

David Noveck <davenoveck@gmail.com> Tue, 21 May 2019 09:52 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35104120048 for <nfsv4@ietfa.amsl.com>; Tue, 21 May 2019 02:52:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3ZVQzHD31oc1 for <nfsv4@ietfa.amsl.com>; Tue, 21 May 2019 02:52:43 -0700 (PDT)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28842120108 for <nfsv4@ietf.org>; Tue, 21 May 2019 02:52:43 -0700 (PDT)
Received: by mail-ot1-x32d.google.com with SMTP id r10so15778780otd.4 for <nfsv4@ietf.org>; Tue, 21 May 2019 02:52:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bBz00dn0mYxnb0UR0d2HYETzmXYafFFBNZ/HM3iStdw=; b=WbmIo4pWZcTjc/pmnzXgMV5O8WkTyx4KgWCXN/JvZcLmeO+LThEk1wP6ylXRwujqaB 9OGzuF0PjsQosZzwX3RyjJf6S5zK2WjqvVgt970Zupb7310iOADf7x0qQKcURYnt8V54 X3NQhrVnm5vSEC6rPsQE0C3v/NcupGd1tTSTswkpNZKPbMmKo3eQOHnf0LGYs2/amFfP zD9rKgLd+Dfvh2XxdbaOENXKWYpuDfQMoryCE5qPMRs4e7/xin7GpLHk2D9mj6oyjitk c/Zv8uoC7orFTS9D28tQe6Z5brCkKn2F4h7SnIpjFjCIuZxCZ0nPoV+B5usnl9JVTgrB /28Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bBz00dn0mYxnb0UR0d2HYETzmXYafFFBNZ/HM3iStdw=; b=GGNuSEzW5H+ilZPU/od/CYunlgN5IED00uW6qsjALX5+VLGbLRHabOnaTtSEFK8sN6 2rmvsmpSibGfZmMsNkEMIDAzMbpV+o8CdlRHjqXETSKdJ5ULH0Rax59a1625WslcJKas sj+SyaI1XWpjn4vOW9ReY4dhSVkjYKaoEOGh6PqHjwnCqPD7Oy7fjEqXSZ6HGSjo4zjw ShQFo2boYPkmFi6eirY4hAjP2JrMHEy9z23aF9hHlXxlPKQib1r0miKTxg+DP+JJoGbf lOCa5LIO1szgZ/477kwNd2V5xclxdfERP+n36efhVwvjVpYmTW5opb+i5ImRz9WOPF/C Grrg==
X-Gm-Message-State: APjAAAWr5x0KqkYg8POL36LVEOAatFzi926GijlITaKtIdf/EpyPmOtJ 24fuBG6GAZXU4tjNP9AA2kRojQi7QcooT1tBwQk=
X-Google-Smtp-Source: APXvYqw+EJrGchDkG4gCXVPJQQqErcH5aSmkEYuanLQs3Yq7qc7+zBcmCmICpjiM1d05S6nROPigADoo3J4zFPk+9Z0=
X-Received: by 2002:a9d:7a59:: with SMTP id z25mr18976177otm.77.1558432361905; Tue, 21 May 2019 02:52:41 -0700 (PDT)
MIME-Version: 1.0
References: <CADaq8jc2FoNEYHp282hxjY3EnWH7qQhF=WHomp+W9O5qf85USw@mail.gmail.com> <AACE7624-98E3-47AE-AA4F-BBD752A818AD@oracle.com>
In-Reply-To: <AACE7624-98E3-47AE-AA4F-BBD752A818AD@oracle.com>
From: David Noveck <davenoveck@gmail.com>
Date: Tue, 21 May 2019 05:52:30 -0400
Message-ID: <CADaq8jeKEN9MY9hs859hJxfyCjeObOR1vBdWMyjFGF9g+KhnfQ@mail.gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000056822a058962cf41"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/iNqf0R8E4GcKOU-DzqQPx3DPvUc>
Subject: Re: [nfsv4] Review of draft-ief-nfsv4-integrity-measurement-04
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 May 2019 09:52:46 -0000

Thanks for the quick response.    I look forward to seeing -05.

Rather than subjecting each other (and the working group) to a
series of messages with long strings of >'s, let me try to summarize
our remaining disagreement by noting that you are uncomfortable with
my description of this as a linux-only feature and deny that this
is atypical by citing a number of other features that have only a
single implementation, in Linux.

I agree that these features are de facto Linux-only features.   I think it
is relevant to note two reasons that I consider the im stuff different,
making
it, in -04 and probably in -05, a de jure Linux-client-only feature.   In
-00,
there was an attempt to make this client-neutral but those efforts seem
to have lapsed.   Note that:

   - Unlike the other features you mentioned, the word "LINUX" appears as
   part of the attribute name, as opposed to the use of "PROVENANCE" in -00.
    My interpretation of this shift is that it indicates a decision to treat
   this as a Linux-client-only feature, rather than one which just happens to
   have only a single current client implementation.
   - With what is in the spec, it is impossible to write a non-Linux client
   implementation, because the format of the IMA metadata is not described.
    There have been requests to provide this and it has not been provided and
   I'm not sure if I will ever understand why it has not.   In any case, while
   the server can treat this as uninterpreted data, a client implementation
   cannot, so that, until this is is specified, the ima stuff is, from the
   client point of view, a Linux-only feature.


On Mon, May 20, 2019 at 2:32 PM Chuck Lever <chuck.lever@oracle.com> wrote:

> Hi Dave, thanks for your thorough review. Comments and responses inline.
>
> > On May 19, 2019, at 5:41 AM, David Noveck <davenoveck@gmail.com> wrote:
> >
> > General Comments
> >
> > Context of Review
> >
> > Development of this document has gone on for a considerable time and it
> appears to have reached something close to its eventual final form.
>  Therefore it is appropriate consider the path forward and specifically
> what would be necessary for the document to be ready for WGLC.  That issue
> will be the focus of this review.
> >
> > Overall Evaluation
> >
> > This document is in pretty good shape but I feel that there are still a
> few matters, beyond the minor editoral issues that consitutute the bulk of
> the material in Comments by Section, that need tro be dealt with before
> WGLC:
> >       • I feel that some editorial work needs to be done in being more
> explicit about the basic  approach taken in this document.  There have, in
> the recent past, been concerns expressed about this approach and feel it is
> quite possible that such concerns will be raised as part of WGLC.   These
> issues are discussed in Potential Concerns about the Basic Approach but I
> don't feel that there is anything that the author can reasonably do to
> address them, partly because no specific issues have been raised, beyond
> the dissatisfaction/unease already mentioned.  Instead, as discussed below
> in Clarity about Goals and non-Goals, I feel it would be best if the author
> was more explicit about the limited goals of this document, continuing an
> existing trajectory from -00 to -04.
> >       • Although, for the most part, the current document follows the
> model of treating the IMA metadata as uninterpreted data whose format
> (beyond a necessary length limit) is not its concern, there are some areas
> where that division of labor is not strictly maintained, which poses issues
> for server implementers.   For further discussion of these areas, see
> Issues for Server Implementations.
> > Potential Concerns about the Basic Approach
> >
> > The major area of potential concern centers around the fact that there
> is likely to be only a single client implementation in that the document
> does not  provide sufficient information for a client to be written and
> there is no point for anyone to write another client implementation.   This
> can be accurately described as a Linux-only feature and there is no point
> in having multiple competing implementations unless one has gone horribly
> wrong.
> >
> > On the other hand, the document generally provides sufficient
> information to allow multiple server implementations to be written and
> tested against the Linux krnel client implmentation being written.
> >
> > This is an atypical pattern for the working group and it is probably an
> atypical one for the IETF as a whole.   During working group last call, it
> is likely that concerns traceable to this issue will be raised as they have
> in the past.   It is important that we have a consensus on the fact that we
> want to do this although it is not necessary to have a consensus on why we
> are doing it, as people may well differ on why we are doing this and thus
> we may might not  have a policy about such one-client-only features going
> foward.
>
> I could quibble with exactly how you stated this, but I agree that:
>
> - the practical outcome is that for some time -- maybe forever -- there
> will
> be a single operating system (Linux) that has the need for NFS client
> support
> for storing and retrieving IMA metadata.
>
> - The primary reason to create this extension is to enable broad support
> for
> the storage of IMA metadata on NFS servers.
>
>
> However I do not agree that this is a precedent or atypical pattern. The
> nfsv4
> WG has already published RFCs where there is, practically speaking, a
> single
> client implementation:
>
>  - NFSv4 Security Labels; the purpose of these was to store SELinux
> labels, for
>    which there is no standard specification. See RFC 7204 and RFC 7862.
>
>  - NFSv4 support Linux user xattrs; there is no standard that describes
> what
>    these are, save the Linux implementation and man pages. See RFC 8276.
>
>
> > Clarity about Goal and non-Goals
> >
> > As this docment has been developed, there has been a shift from an
> earlier state in which there were somewhat half-hearted attempts to provide
> for the posssibility of other clients to the current state in which it is
> qiuite clear that this is, as descibed in Potential Concerns about the
> Basic Approach a one-client-only feature.   I believe it would be helpful
> to be more explicit about that fact in a number of places, so that the
> document can address the concerns of those who have trouble with that
> approach head-on.
>
> No argument from me. I'm pretty close to the subject matter, so any help
> with
> such text would be appreciated.
>
>
> > As I understand things, the Linux IMA metdata is essentally, from the
> server's point of view, a piece of uninterpreted data, just as user data
> and extended attributes are, although there are  a few remaining issues
> discussed in Issues for Server Implementations that need to be addressed.
> However, unlike other sorts of user data, this does have an internal
> structure known to the client implentations and not documented in this
> document.   That information would not be needed in a one-client-only
> implementation but it is typically provided in feature descriptions, so it
> would be best if this point is mde explicitly.
>
> Sure. I feel that is already stated in the Introduction. If there is a way
> to
> make it more clear, I am open to suggestions.
>
>
> > Issues for Server Implementations
> >
> > The following issues are discussed in more detail in 5.2.1.  Authorizing
> Updates to IMA Metadata:
> >       • As described above, the basic architecture is that the server is
> to treat IMA metadata as uninterpreted data, yet there are some indications
> that this is not always so.
>
> Here's where I can state my quibble: interpretation of this metadata is by
> a security module loaded by the operating system, not by the NFS server or
> client implementation themselves.
>
> To wit: A Linux host acting as an NFS server will have the capability to
> interpret IMA metadata, and in fact it does so before serving IMA-protected
> file content. The actual behavior when appraisal fails depends on the local
> IMA policy that is in effect.
>
> Moreover, a Linux NFS server typically has a user execution environment
> where IMA policies need to be enforced for locally-running applications.
>
> Therefore there are some cases where it is very reasonable for an NFS
> server
> to have the ability to interpret the IMA metadata. Section 5.3 provides
> examples that might help explain these scenarios.
>
>
> >       • The issue of the proper privilege to update IMA metadata needs
> to be clarified.
>
> I agree this issue still needs work, but I'm not sure how to proceed.
>
>
> > Comments by Section
>
> I'll look into each of the below comments as I prepare the next revision of
> this document. The fresh revision should be ready before IETF 105.
>
>
> > Title
> >
> > Consideration should be given to including the word "Linux" in the
> title, since this is being defined as a Linux-only feature.
> >
> > 1.  The Linux Integrity Measurement Architecture
> >
> > In the second sentence of the first paragraph, I'm wondering about the
> adjective "primary".  Since I'm having trouble imagining what a secondary
> goal might be, I wonder if "primary" should be deleted.
> >
> > With regard to the penultimate paragraph:
> >       • I don't understand the "therefore" in the second sentence.  I'm
> clear that the format is not described in this document, and it does not
> need to be since servers don't need it and there is only one client
> implementation.  I think we need more clarity about whether the format
> cannot be described in this document or whether it could but is not present
> because it is unnecessary.
> >       • In the third sentence suggest replacing "NFS clients" by "Linux
> NFS clients."
> >       • Suggest adding a final sentence such as the following :
> > Information about the format of IMA metadata is not needed by server
> implementation as this data can be treated just as is other data whose
> format is defined by others (e.g. user  data and extended attributes).
> >
> > 4.   Managing IMA Metadata on NFS Files
> >
> > While I haven't found many issues with the material in the various
> subsections of this section, the material is incomplete in that it does not
> deal with all possible use of the IMA metdata attribute in
> attribute-related operation but only in those that the author blieves
> (probably correctly) are likely to be used.   In particular,
> >       • There is no mentiion of VERIFY/NVERIFY.   It is not clear if
> they are considered invalid, but I'm assuming they aren't.
> >       • There is no mention of the specfication of attributes in
> CREATE.   It needs to be specfied if this is valid or not.
> >       • In sections 4.2 and 4.3 the text seems to assume that the IMA
> metadata attribute will not be set/interrogated together with other
> attributes.
> > One other issue that applies to multiple subsections concerns the phrase
> "but the object itself does not support the FATTR4_LINUX_IMA attribute".
>  It needs to be defined what types of objects are to have this support.
>  Otherwise, you have a Total Interoperability Nightmare (tm :-).
>
> I suspect it isn't all that bad, but I agree that Section 4 needs to
> discuss these three areas.
>
>
> > 4.3.  Retrieving IMA Metadata
> >
> > In the third paragraph, there is a stray reference to the
> FATTR4_FILE_PROVENANCE bit which needs to fixed.
> >
> > 5.2.1.  Authorizing Updates to IMA Metadata
> >
> > There are a number of issues in this section where sufficient
> information is not given for  a server implementation to be written or
> there is a reference to the possibility that the server will implement
> behavior based on knowledge not provided in this spec, as mentioned above
> in  Issues for Server Implementations.   Given the current scope of the
> problems, I'll reproduce the existing section in italics and respond to
> each element that  I believe raises problems:
> >> A participating server should ensure that modifications to IMA metadata
> are done only by appropriately authorized agents.
> > That's unexceptionable, but the problem is that the server is given no
> way to determine exactly when a request is made by an "appropriately
> authorized agent".    As ACLs are the primary means by which authorization
> decision about actiions on files are determined in NFSv4, it would be best
> if the specfication told how the file's ACL could be used to make this
> determination.
> >> Such agents usually include only agents with super-user privileges.
> > Since this imples that there are also unusual situations, the "usually"
> is purely informational.  Again, what is needed is a specfication of how a
> server is to make the authorization.   The obvious choice is to allow this
> to be set iff the  file data can be written but if it were that simple, the
> spec would simply say that.
>
> The existing implementation of IMA allows changes to the IMA metadata
> only if CAP_SYS_ADMIN is set (ie, the root user privilege). I will have
> to check into the rationale for this choice.
>
>
> > If it is something else, what is needed is:
> >       • A specification of that other approach.
> >       • An explanation of why the obvious choice is not OK.
> >> The NFS server MAY confirm that the new IMA metadata actually verifies
> the file content correctly before storing it.
> > There are a number problems with this:
> >
> >       • It contradicts the basic idea that the server is to treat IMA
> metadata as uninterpreted, as it does user data,   I for one, would not
> want an NFSv4 server to reject a WRITE of a .c file because it didn't like
> my comment indenting :-)
> >       • Since the format is not defined in this document, it is
> basically saying that the client that the server "MAY" refuse a request to
> store IMA metadata pretty much whenever it feels like it and that clients
> have to deal wit that.
> >       • There is no specification, either here or in Section 4.2, of
> what error SETATTR is to return in this event.
> > If this is necessary to accommodate Linux file systems that are aware of
> the format of this data, enforce it, and cannot be changed to treat this
> data according to the basic architecture treating this as uninterpreted
> data, consideration should be given to making this a "SHOULD NOT".
>
> Agreed, the MAY doesn't make sense here; I think that was a misdirected
> edit of another area of the document. Two alternatives to address this
> issue are to remove that sentence, or change MAY to MUST NOT.
>
>
> > 7.  Security Considerations
> >
> > The last paragraph has the following issues:
> >       • It ignores the fact the denial-of-service triggered by mismatch
> of data and IMA-metadata can result from changing the data as well as
> changing the IMA metadata.
> >       • It doesn't define "suitable level of pivilege".
> >       • It refers the reader to section 5.2.1 for details while that
> section has no useful details.
>
> --
> Chuck Lever
>
>
>
>