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

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

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

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

On Mon, Nov 11, 2019 at 4:57 PM Chuck Lever <[email protected]> wrote:

>
>
> > On Nov 11, 2019, at 2:43 PM, David Noveck <[email protected]> wrote:
> >
> >
> >
> > On Fri, Nov 8, 2019, 10:12 AM Chuck Lever <[email protected]>
> wrote:
> >
> >
> >> > On Nov 7, 2019, at 6:13 PM, David Noveck <[email protected]>
> wrote:
> >> >
> >>
> >> It appears that draft-ietf-nfsv4-integrity-measurement can't move
> >> forward without some description of the IMA metadata format.
> >
> > It is my understanding that you already plan to do that in -08.
>
> That is what I proposed last week. Now I'm thinking the description
> could be a separate document. Certainly a description could be
> published separately by the IETF (eg., nfsv4, rats or teep) or it
> could come from some other SSO (such as TCG).
>
>
> >> My preference would be that the Linux community is responsible for
> >> the process and document(s) that describe their own format.
> >
> > That's very sensible but that doesn't mean it's going to happen.
>
> As a card-carrying member of the Linux community, I can attempt to
> get it done myself. Two issues:
>
>  - Who will be responsible for maintaining the publication as new
> Linux IMA formats are introduced. IMA is currently an active effort,
> and I anticipate some integration with fs-verity will require a new
> IMA metadata format.
>
> - How long will it take to ensure the format is not encumbered by
> patent or software license. I have contacts at the Linux Foundation
> that I hope can help address this issue. I will also discuss this
> with any copyright holders.
>
>
> >> Failing
> >> that, a description can be added to integrity-measurement, as I
> >> recently proposed.
> >
> > Understood.
> >
> >
> >> To make an IANA registry a sensible thing to do, at least one more
> >> independent integrity metadata format will have to be identified.
> >
> > I think one has already been identified.  To make this scheme work,
> there will need to have a common metadata format implemented.
> >
> > Once it is implemented, it will need to be specified, leaving you with
> following tasks:
> >       • Identifying a victim to provide it.
> >       • Figuring out when/where it will be provided.
> > The virtue of the IANA registry is that it gives you the ability to
> defer these tasks.
>
> Deferral would be nice, as that would enable integrity-measurement
> to move forward sooner (assuming Spencer's objection is lifted).
> But it might be unnecessary if I can get a document put together
> and signed-off by others in the Linux community in the next few
> months.
>
> We did try an IANA registry before, and I'm willing to consider
> that again to help move this along. The e-mail conversation a few
> months ago rat-holed on whether or not there would be an actual
> need for multiple metadata formats, as I recall. We can put aside
> the question of over-engineering and decide simply that the document
> will start with a registry containing one format discriminator.
>
> There is also the question of whether the format discriminator field
> not only marks the internal 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).
>
> IMA, for example, already uses two xattrs, security.ima and
> security.evm, that can co-exist on the same file. It would be slick
> to add support for security.evm simply by adding another entry into
> the IANA registry.
>
> Before I go too much further, however, I would like to hear from
> Spencer if he believes these changes would adequately address his
> concerns.
>
>
> --
> Chuck Lever
>
>
>
>

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