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

From: David Noveck <[email-masked]>
Date: Sun, 19 May 2019 05:41:01 -0400

*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.

*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.

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.

*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.
   - The issue of the proper privilege to update IMA metadata needs to be
   clarified.

*Comments by Section*

*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 :-).

*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. 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".

*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.

---

From: Chuck Lever <[email-masked]>
Date: Mon, 20 May 2019 14:32:32 -0400

Hi Dave, thanks for your thorough review. Comments and responses inline.

> On May 19, 2019, at 5:41 AM, David Noveck <[email-masked]> 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.
> 
> 	• 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.
> 	• 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
> 
> 	• 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

---

From: David Noveck <[email-masked]>
Date: Tue, 21 May 2019 05:52:30 -0400

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 <[email-masked]> wrote:

> > 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
> 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
> 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.
> > 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.
> >
> > 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.
>
> 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
> >       • As described above, the basic architecture is that the server is
> to treat IMA metadata as uninterpreted data, yet there are some indications
> > Consideration should be given to including the word "Linux" in the
> title, since this is being defined as a Linux-only feature.
> >
> >       • 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
> >       • 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.
> FATTR4_FILE_PROVENANCE bit which needs to fixed.
> >
> > 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.
> > 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 NFS server MAY confirm that the new IMA metadata actually verifies
> the file content correctly before storing it.
> >       • 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.
> >       • 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.

---

From: Chuck Lever <[email-masked]>
Date: Tue, 21 May 2019 13:41:49 -0400

> On May 21, 2019, at 5:52 AM, David Noveck <[email-masked]> wrote:
> 
> 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, 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> > On May 19, 2019, at 5:41 AM, David Noveck <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > General Comments
> > 
> > Context of Review
> > 
> >       • 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..
> >> Such agents usually include only agents with super-user privileges..  
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Tue, 21 May 2019 15:00:38 -0400

Hi Dave-

> 	• 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.

I changed the name because of comments from you and Craig.

I used LINUX because IMA is "specified" by the Linux implementation,
not because IMA is implemented only on Linux.

So let's pick a name that does not have LINUX in it. I see that RFC
8276 uses

      /// typedef component4     xattrkey4;
      /// typedef opaque         xattrvalue4<>;

No sign of "linux" there. I'm open to suggestions. If no-one has one,
I'll use FATTR4_IMA in the next revision.

> 	• 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.

The attributes added by the proposed protocol extension are
completely specified in this document. Any NFS client can enable
access to and updates of IMA metadata using this document.

Why would a client without an IMA implementation want to do this?
For example, the metadata can be copied with the file's content.
There is no need for any interpretation of that metadata on the
copying host, it is simply an opaque blob. But not copying that
blob means there is unwanted loss of information in the copy.

If, for instance, the Linux IMA tool "evmctl" is ported to other
operating systems (if they have xattr support), IMA metadata is
exposed to user space on that OS and can be read or set via evmctl.

I should mention that the changes to the Linux NFS client and
server implementation do not know anything about the form of the
metadata, nor do they need to.

> 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.

I have explained repeatedly on list why it is not possible. There
is no specification for IMA, there is only an implementation. What
could be cited in my document? I stated that up front when I
presented during last summer's IETF meeting. This is the major
issue with this document. There is no specification of IMA to cite.

I have also explained why there is no need for the document to
describe the metadata format: NFS acts only as a conduit, just like
it does for user xattrs or file content. The metadata is not
interpreted by either the NFS client or server implementation.

This is the same as the local filesystem case. Local filesystems
store the metadata, and a separate security module (or user space
programs like evmctl) interprets it. To the local filesystem, IMA
metadata is completely opaque. It is no different for NFS.

[ As soon as this document provides format details, it will become
the specification for IMA. I'm not sure the IETF or the WG wants
to sign up for that responsibility, and IMO the Linux community
would not settle for being tied down by an RFC either. ]

> In any case, while the server can treat this as uninterpreted data, a client implementation cannot,

I believe that is a false assertion.

When I wrote "interpreted /on/ the NFS client" I meant on the host
where the file content is accessed via NFS and then subsequently
used. The NFS client implementation itself does not interpret the
metadata any more than it cares what's in the file's byte stream.

So my quibble yesterday is now a full blown objection to your
characterization: Neither the NFS client implementation nor the
NFS server implementation interprets IMA metadata. Both are pass-
through agents.

The metadata is interpreted by a separate (trusted) agent whenever
the file content is read (or executed). But it is totally opaque
to the NFS protocol and implementations.

In this sense, IMA metadata is precisely the same as a user xattr.

> so that, until this is is specified, the ima stuff is, from the client point of view, a Linux-only feature.

Perhaps it is, practically speaking, but I disagree with your
reasoning.

I will re-write the Introduction again to clarify the above points.

--
Chuck Lever

---

From: "Everhart, Craig" <[email-masked]>
Date: Tue, 21 May 2019 19:54:46 +0000

Hi Chuck.

It's a little specious to cite RFC8276 as a model for a Linux-only feature, isn't it?  It goes to some pains to describe how its xattrs are supported in multiple operating systems (Linux, FreeBSD, Windows's NTFS, with even Swift).  It suggests enough detail for some of the xattrs that it's imaginable that there might one day be semantic interoperation: message-IDs, a URL, checksumming, crypto hashing, source application, etc.  All this is lacking in the IMA document.

One particularly difficult omission from the IMA document is some understanding of the domain of discourse.  In the Linux document, the domain is one Linux machine.  Presumably, the draft intends to extend this domain to all the clients connected to the Linux machine?  It's not clear.  What would it mean?  (What is being intended?)  Is there any guarantee that the IMA implementations are compatible?

How is the "identity of the last modifier of a file's content" converted to a keyed hash?  Is that "identity" something that has meaning outside the single Linux machine, or the one that's acting as the server here?

NB.  I tried to go to the URIs given in the -04 draft; the first directed me to a string of software versions--not the document that I was expecting--and the second didn't resolve.

		Craig

---

From: Chuck Lever <[email-masked]>
Date: Tue, 21 May 2019 16:56:13 -0400

> On May 21, 2019, at 3:54 PM, Everhart, Craig <[email-masked]> wrote:
> 
> Hi Chuck.
> 
> It's a little specious to cite RFC8276 as a model for a Linux-only feature, isn't it?

The purpose of that document was to enable support for Linux xattrs
in particular. I'm not aware of plans to implement support in other
OSes; it was driven by a desire to support these objects in Linux.

The fact that there are similar objects in other operating systems
is used in RFC 8276 merely as rationale. It is not a normative
statement.

Note that there is no standard specification for extended attributes
or for the OS APIs that access them.

> It goes to some pains to describe how its xattrs are supported in multiple operating systems (Linux, FreeBSD, Windows's NTFS, with even Swift).  It suggests enough detail for some of the xattrs that it's imaginable that there might one day be semantic interoperation: message-IDs, a URL, checksumming, crypto hashing, source application, etc. All this is lacking in the IMA document.

Sections 2 through 6 of RFC 8276 act as Informational rationale, not
as Normative requirement. I don't see where any of the text in Section
2, for example, provides a detailed enough description that would
enable me to build an interoperable implementation of user xattrs.

For example, I do not see a citation that specifies the format of a
"message-ID" in RFC 8276, either Normative or Informative, and it
is not otherwise described in RFC 8276.

The Introduction of integrity-measurement goes into similar detail
for a similarly informative purpose. In fact that section provides
quite a bit more detail than RFC 8276 does for the particular use
case of IMA metadata.

> One particularly difficult omission from the IMA document is some understanding of the domain of discourse.  In the Linux document, the domain is one Linux machine.  Presumably, the draft intends t…

IMA metadata is upper layer application data, just like xattrs are.

We have never specified a similar interoperability requirement for
databases stored in NFS files, or for information transferred via
TCP. Questions about interoperability belong in the upper layer in
those cases, and here too, and not in the transport layers.

> How is the "identity of the last modifier of a file's content" converted to a keyed hash?  Is that "identity" something that has meaning outside the single Linux machine, or the one that's acting a…

The hash is computed from the file content.

The hash is signed with a certificate which identifies the source of
the file content or an authority that can verify that the content
is valid.

That certificate was signed by a trust authority that is recognized
on the client hosts where the hashes are appraised.

Any changes to the hash or the file content will be detected when
the file is appraised before use. That makes the content immutable
and the source of the content is identified by the signing cert.

> NB.  I tried to go to the URIs given in the -04 draft; the first directed me to a string of software versions--not the document that I was expecting--and the second didn't resolve.

[1] is http://downloads.sf.net/project/linux-ima/linux-ima/Integrity_overview.pdf

I was able to download that document, entitled "An Overview of the Linux
Integrity Subsystem".

[2] is https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-Summary_04292008.pdf

I was able to view that document in my browser.

FYI, in the next revision, [1] has been replaced by a reference to:

Sailer, R., Zhang, X., Jaeger, T. and L. van Doorn, "Design and
Implementation of a TCG-based Integrity Measurement Architecture",
Proceedings of the 13th USENIX Security Symposium, August 2004.

--
Chuck Lever