Objections to Section 4.3.2 of integration-measurement-06

[chucklever]

An NFS version 4.2 server needs to ensure that modifications to IMA
metadata are done only by appropriately authorized agents.

That's true but it is very difficult to do when there is no definition of "appropriately authorized agents"

Although
access to file content is typically controlled by ACLs and permission
bits, these mechanisms do not apply to IMA metadata.

First of all no reason is given as to why this is so. Note that:

• These are the mechanisms used throughout the NFSv4 protocols so it would seem that the variance would call for some explanation.
• Allowing independent decisions about whether to allow a write to a file and when to allow setting its IMa metadata allows the possibility that someone will mliciously set the IMA Metadata. While the cryptographic nature of the signature prevents signing of an inappropriately modified file, the possibility exists that a malicious actor could cause a denial of service by storing an inappropriate/invalid signature.
• It is unclear whether the phrase 'these mechanisms do not apply" is intemded normatively ot not. If it isn't, then there is no nornative guidance on this point whatever. On the other hand, if it is normative, then it is bizarre that the one factor that the server is not allowed to consider in deciding whether this is being done by an "appropriately authorized agent" is one that everyone else in NFSv4 uses to make these sorts of decisions.

The question of "who is authorized to modify IMA metadata" is often
left to the server's local IMA security policy.

Perhaps so, but without information about such security policies, this isn't all that helpful.

In addition, the
issue of whether to allow a particular IMA metadata update has no
bearing on protocol interoperability, as long as the server sticks to
returning NFS4ERR_ACCESS or NFS4ERR_INTEGRITY, as appropriate.

I don't agree. If the client tries to do an operation and is not allowed to do it, then you have an instance of inter-non-operability :-( Also, if the client has no indication of why this failed (wrong user, wrong client, wrong something else) there is no way to decide how to work around the failure.

Thus,
to enable server implementation flexibility,

It has to be recognized that server flexibility is not an unalloyed good, and that in granting such a large degree of fleixibility (almost unbounded) to the server, you basicallly undercut the value of defining a protocol, to provide interoperability.

the current document
treats the following recommendations as implementation guidance
rather than as normative protocol requirements.

If these are not normative requirements, then there are no normatve requirements and I don't see how you can get by saying essentially that the server is free to accept or reject requests as it chooses.
Also, although the word "recommendations" is used, ther are no actual recommendations to make any particular choice as better than another. As to "implementation guidance" what is the implemenation being guided to do?

Possible NFS server implementations include limiting IMA metadata
update authority in the following ways:

The use of the word "include" suggests that other ways are allowed/recommended or part of what you are guiding the server to do. These include some silly ones (e.g. do not allow the change of ima metadata in a month that does not include an "r") and some that are not silly at all (e.g. do not allow the change of IMA metdata when done by an unauthenticated client using AUTH_SYS).

Particular users
A server might allow IMA metadata updates only by UID 0 or by a
client's machine principal.

If applied to an AUTH_SYS client, this constitutes a glaring security hole. I think this would be Ok, for non-auth-sys as long as NFS4ERR_WRONGSEC is returned if AUTH_SYS is used.

Particular clients
A server might allow IMA metadata updates only from specific
client IP addresses.

Since the source IP addresses can be spoofed, the value of this is limited.

File owners
A server might allow IMA metadata updates only by the file's owner
or group owner.

I think this would be OK, as long NFS4ERR_PERM is returned when the owner is wrong.

No remote updates
A server might always return NFS4ERR_ACCESS when an NFS client
sends a SETATTR request that updates IMA metadata.

If a server is not allowing SETATTR of this attribute, it is really treating this as a get-only attribute, in which case NFS4ERR_INVAL would be the appropriate error to return.
Since each of the above clearly has ann existing constituency, making intra-community comporomise difficult to achieve, let me try to articulate my bottom line:

• If we have to live with these four approaches, then OK :-( but I don't think we can live with an infinite number of possible approaches.
• These restrctions have to be in addition to the ability to write the file in question, rather than as a potential replacement.
• It needs to be clear why a request was rejected, either due to a distinct error code or some sort of fs-wide policy attribute.
• If there are existing servers that do something bogus (e.g. accept an AUTH_SYS uid zero as determinative), then that fact can be noted but we should not recommened or in any way guide implementations to adopt such dubious practices.

[chucklever]

From RFC 5661:

5.5. Set-Only and Get-Only Attributes

Some REQUIRED and RECOMMENDED attributes are set-only; i.e., they can
be set via SETATTR but not retrieved via GETATTR. Similarly, some
REQUIRED and RECOMMENDED attributes are get-only; i.e., they can be
retrieved via GETATTR but not set via SETATTR. If a client attempts
to set a get-only attribute or get a set-only attributes, the server
MUST return NFS4ERR_INVAL.

15.1.6.1. NFS4ERR_ACCESS (Error Code 13)

Indicates permission denied. The caller does not have the correct
permission to perform the requested operation. Contrast this with
NFS4ERR_PERM (Section 15.1.6.2), which restricts itself to owner or
privileged-user permission failures, and NFS4ERR_WRONG_CRED
(Section 15.1.6.4), which deals with appropriate permission to delete
or modify transient objects based on the credentials of the user that
created them.

15.1.6.2. NFS4ERR_PERM (Error Code 1)

Indicates requester is not the owner. The operation was not allowed
because the caller is neither a privileged user (root) nor the owner
of the target of the operation.

15.1.6.3. NFS4ERR_WRONGSEC (Error Code 10016)

Indicates that the security mechanism being used by the client for
the operation does not match the server’s security policy. The
client should change the security mechanism being used and re-send
the operation (but not with the same slot ID and sequence ID; one or
both MUST be different on the re-send). SECINFO and SECINFO_NO_NAME
can be used to determine the appropriate mechanism.

The SETATTR operation is permitted to return:

NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR, NFS4ERR_BADOWNER, NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, NFS4ERR_DEADSESSION, NFS4ERR_DELAY, NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, NFS4ERR_EXPIRED, NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_LOCKED, NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PERM, NFS4ERR_REP_TOO_BIG, NFS4ERR_REP_TOO_BIG_TO_CACHE, NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, NFS4ERR_STALE, NFS4ERR_TOO_MANY_OPS, NFS4ERR_UNKNOWN_LAYOUTTYPE, NFS4ERR_WRONG_TYPE

INVAL, ACCESS, and PERM are all permitted status codes, but WRONGSEC is not. In this case, I think allowing IMA metadata updates when the file content is writable, without any further adornment, is an adequate baseline.

[chucklever]

Possible alternative approach:

Typically, an NFS server allows a user to update IMA metadata whenever the user is permitted to modify the file's content. This is consistent with similar mechanisms already used throughout the NFS protocol.

If the user is not permitted to update the IMA metadata, SETATTR(FATTR4_IMA) MUST return NFS4ERR_PERM.

If the NFS server implementation does not support remote modification of IMA metadata, SETATTR(FATTR4_IMA) MUST return NFS4ERR_INVAL.