[Cc'ing Roberto]
On Mon, 2020-01-06 at 09:27 -0500, Ken Goldman wrote:
> On 1/4/2020 6:32 PM, Mimi Zohar wrote:
> > The "ima-modsig" template may include the "sig" and/or the "modsig"
> > fields. As the "d-modsig" and "modsig" are tied together, either both
> > are defined or neither are defined. The file hash ("d-ng") must
> > always exist.
> That's clear for the predefined (is there a formal term for them?)
> templates. How would this be specified when IMA permits custom templates?
"predefined" is fine, or "builtin".
>
> E.g., I can create a template 'modsig', I have the signature but not the
> file data hash. I can create a template 'd-modsig' that has the file
> data hash but no signature.
That should be flagged as an error.
>
> With custom templates, the attacker can create any IMA log, and the
> parser has to handle it.
>
> Note: When you say "either both are defined or neither is defined",
> this may be enforced by the official IMA code. However, the attacker is
> free to modify the IMA code to send any log it likes. The parser has to
> know what to do.
An attacker shouldn't be able to spoof the PCR quote. As previously
discussed, the verifier should first walk the measurement list
calculating the PCR values. Only if the PCRs match, should the
verifier attempt to parse the individual template data records.
>
> That is, an event log specification (which I'm trying to write) has to
> state precisely that the dependencies are and what should be rejected.
> For example, it might say (if this is corrct):
>
> 1 - If d-modsig is present, modsig MUST be present. Else error.
> 2 - If modsig is present, d-modsig MUST be present.
Yes
> 3 - If ???, d-ng MUST be present.
Templates were designed to be extensible, allowing new fields to be
defined and combined. I can't say definitively that there will never
be a case when the "d-ng" field isn't needed, but at least for the
moment that is the case. Perhaps with IMA fs-verity support, only a
digest and signature, based on the merkle tree file hash will be
needed.
Mimi
