Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-integrity-measurement-03.txt

[David Noveck <[e-mail]>]

> I do want to have multiple FPI
> blobs per file.

If so, then this desire could be accommodated more simply than by
allowing each such blob type (fpv_type) to be invidually settable
and retrievable as is suggested in -03.  The existing NFSv4 attribute
model would need substantial change to accommodate that.

I think the best way to provide for the possibility of multiple blobs would
be to make the provenace  attribute an array of blobs.   I think the
following would work but I might have messed up the typdef syntax.

typedef file_prov4 fattr4_file_provenance[];

Those who sign content will need to generate all the blobs they want
to support. I don't see why setting each blob needs to a separate operation.

Assesors, could get the entire blob set and fairly easily find the blob(s)
they want to access.

> IMA has one for file content, and another one
> for file attributes (the EVM blob). Both can exist at the same
> time.

OK.

> I'm specifying only the IMA blob for NFS at this time, as
> explained in a prior email,

As I understood it, wou were not actually specifying it but were
simply directing people to a description.   I can't recall the details, but
I recall some complexity about whether that description was actually
a specfication.

> but you should assume that more blobs
> will be coming in the future.

They might and implemeters will make their own decisions about how much
space to allocate to store potenial blobs.

On Thu, Nov 8, 2018 at 1:23 PM Chuck Lever <[e-mail]> wrote:

>
>
> > On Nov 8, 2018, at 12:03 PM, Everhart, Craig <[e-mail]>
> wrote:
> >
> > Hi Chuck, just one point.
> >
> > On 11/8/18, 11:54 AM, "Chuck Lever" <[e-mail]> wrote:
> >
> >>   This means _any_ change
> >>   to the content between the time it is generated and the time it
> >>   is used can be detected.
> >>
> >> And detected by only these special tools.
> >
> >    No, the FPI is evaluated by the provenance assessor before each
> >    access of the file.
> >
> > Perhaps you could clarify this architecture.  The menagerie of tools
> that would be modified, this provenance assessor--what is the architecture
> of the system in which these tools exist?  Is the "provenance assessor"
> part of the presumed OS on the NFS client?
>
> We're going in circles now. I've explained this before in e-mail
> and in the document.
>
>
> > Is it active when I read a file with the menagerie (e.g., "cp")?
>
> Depending on policy, it can be.
>
>
> > At backup time?
>
> Depending on policy, it can be.
>
> The primary point of FPI is to prevent the use of corrupted file
> contents. Copying or backing up file content is not necessarily
> considered "use", but an administrator might be paranoid or want
> some notification if tampering has occurred long before a file
> is used. It's also possible that a tool can be constructed to
> scrub a file system to pre-emptively identify corrupted content.
>
> Again, this document is not meant to be a full specification of
> IMA and how it's used. A discussion of tooling is out of scope,
> IMO.
>
>
> > I assume that it will be active when I want to edit the content of a
> source file, or execute a binary executable file.
>
> Most certainly just before a file is executed. If a source file
> is protected, it will be assessed as it is opened but before its
> contents are presented via read(2) or mmap(2). Any edits will
> require that the FPI be refreshed once the file content is stable
> again.
>
> So, now that I'm paged in again, I do want to have multiple FPI
> blobs per file. IMA has one for file content, and another one
> for file attributes (the EVM blob). Both can exist at the same
> time. I'm specifying only the IMA blob for NFS at this time, as
> explained in a prior email, but you should assume that more blobs
> will be coming in the future.
>
>
> --
> Chuck Lever
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>