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

[Chuck Lever <[e-mail]>]

> On Nov 12, 2019, at 9:09 AM, David Noveck <[e-mail]> wrote:
> 
> > There is also the question of whether the format discriminator field
> > not only marks the internal format, 
> 
> I don't understand.   I would think that the format discriminator
> identified the external format.  Of course, as a practical, matter,
> a server implementation might well choode to make the internal
> and external formats the same, since it doesn't really care.

Sorry. Not sure why I used the term "internal" here. I merely
meant the public integrity metadata format.


> > but also allows the storage and
> > retrieval of metadata stored in other xattrs (unlike the discriminator
> > for NFSv4 security labels, which applies only to one xattr).
> 
> From the NFSv4 poiint of view, the particular (system) xattr used 
> for this purpose don't really matter.   Since they are not not
> NFSv4 (user) xattrs, any such assigment is purely an
> implemenation matter.

The issue is similar for NFSv4 security labels, though that ship
has sailed. On Linux each label type is stored in a unique xattr,
but the NFSv4 security label specification requires there be only
one accessible label at a time per file.

Yes, multiple security labels per file does make sense.


> > IMA, for example, already uses two xattrs, security.ima and
> > security.evm, that can co-exist on the same file. 
> 
> That the first of hear of this and your spec does not mention it.

It's not the first time it's been discussed here, and in fact
some earlier revisions of the personal draft version of this
document did discuss EVM, iirc.

IMA is a hash of file content. EVM is a hash of file
attributes. EVM is not supported by my spec simply because
the NFS protocol does not expose all of a file's attributes
(the file's capability settings being one of the most
important attributes that EVM protects). Thus NFS clients
are unable to verify EVM metadata.


> I presume this is because this division into multiple sub-blobs
> is not necessary to implement the protocol you describe,
> although it might be necessary to implement appraisal. 
> 
> > It would be slick
> > to add support for security.evm simply by adding another entry into
> > the IANA registry.
> 
> I don't see why this wouldn't work or why it is even in question.

It's in question because NFSv4 security labels explicitly do not
allow multiple labels per file, but integrity will likely need
that kind of functionality.

During a previous discussion, future EVM support was mentioned as
a reason why having a discriminator field would be a good thing.


> If there is a furure IMA metadata format consisting of these two 
> sub-blobs, it would not affect the protocol yout have described.
> Servers would not care about this sub-dvision while those concerned
> with appraisal would have to be aware of them.  However, they would 
> not need to know anything about how these sub-blobs were stored.

That's correct: EVM is similarly opaque to filesystem implementations.


> I assume on-Disk Linux file systems would use these xattrs, while 
> NFSv4.2 servers with no appraisal capabilities would probably store 
> the whole blob  as-is.

I agree that the protocol specification should remain agnostic about
how NFS servers store integrity metadata. I'd simply like to be able
to store multiple distinct types of integrity metadata on the same
file.


=====

Recall that at least one revision of this document called the metadata
"file provenance information." Craig didn't like that because he felt
it was dishonest about what the purpose of this extension actually
was -- to store Linux IMA metadata.

If the pendulum is swinging back to enabling storage and transport of
generic integrity metadata, perhaps calling this attribute IMA is no
longer appropriate, and some other name would be better.

FATTR4_INTEGRITY_METADATA or maybe just FATTR4_INTEGRITY ?


--
Chuck Lever