Re: Comments on draft-ietf-nfsv4-integrity-measurement-07

> On Oct 29, 2019, at 12:10 PM, Craig Everhart <[email protected]> wrote:
> 
> I think the reason it’s difficult for me to endorse this is that I can’t play in the understanding of integrity, and I’d like to understand any weaknesses.

> Apparently it uses something like what I loosely described, but I have no visibility into it or how it works.

You do have visibility. You can go and look at the references cited
by the document. In fact there's a USENIX paper that explains the
architecture and provides the analysis you are looking for. There's
an open implementation that is available as a prototype and proof of
concept.

But I don't see that kind of analysis as pertinent to whether a file
system can store a blob of metadata. The questions you are asking are
related to whether you want to implement an appraiser on your non-
Linux system. I'm suggesting that's something that can and should
be decided independently.


> Is it using a private key in an HMAC?  If there’s validation of certificates involved, how are they described or registered?  What is the domain of these putative certifications?  Is it meaningful for an NFS server to receive an integrity assertion from one Linux machine and expect that assertion to be validated by a separate Linux machine?

> I know that Chuck doesn’t believe that an NFS server should be able to validate an integrity assertion.  I wonder why not.

That's a needlessly provocative mischaracterization.

IMA does not trust data storage. The only really meaningful appraisal
is done at the time of content consumption. Any other appraisals are
just gravy.

Note that content consumption typically does not occur on servers --
certainly not on NetApp filers, for example -- and consumption
happens after control of the content has passed from the NFS client
implementation to the operating system. The file system is no longer
involved when appraisal actually occurs.

For IMA, NFS client and server implementations are simply links in the
chain between the content provider and content consumers. Validating an
integrity assertion on each link in that chain is OPTIONAL. The only
value added by the extra assertions is identifying at which link the
file content might have been corrupted.

If you believe that it is the NFS server's job to avoid handing out
corrupted data, then your NFS server should perform appraisal before
it honors READ requests. That's a valid point of view. In the Linux
world, the NFS server does have an appraisal engine and policy that
is applied before data is served to NFS clients.

Eventually other NFS servers can have this too. Just not today, because
the Linux IMA appraisal metadata format is not yet standardized.

The NFS client implementation is not involved in appraisal either. This
is because the mechanism of appraisal is common to all file systems. It
would be foolish to have an appraisal mechanism in each file system
implementation, because they all do exactly the same thing.

All I'm saying is that appraisal is separate from transporting and
storing IMA metadata. The question of whether a non-Linux system can
perform appraisal is valid, but orthogonal to whether IMA metadata can
get from point A to point B.


> The NFS wg may have previously allowed client-only attributes into the space of an NFS specification.  I don’t think that it’s right to do that here.  There are too many touch points for an integrity proof.

Again, I'm asking for just a narrow piece of the puzzle: transport. I
am not proposing a complete solution, because the transport is all
that is necessary for NFS, as a file storage system, to play in this
architecture. This is the case for every local file system.

If NFS were to support Trip Wire or some other proprietary data
integrity monitoring and appraisal system, would the nfsv4 WG have the
same qualms about allocating a FATTR4 attribute for it?


--
Chuck Lever



_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4