> -----Original Message----- > From: linux-integrity-owner@xxxxxxxxxxxxxxx [mailto:linux-integrity- > owner@xxxxxxxxxxxxxxx] On Behalf Of Ken Goldman > Sent: Monday, January 6, 2020 5:02 PM > To: Mimi Zohar <zohar@xxxxxxxxxxxxx>; Linux Integrity <linux- > integrity@xxxxxxxxxxxxxxx>; Ken Goldman <kgoldman@xxxxxxxxxx> > Subject: Re: Spec needed for ima-modsig template > > On 1/6/2020 10:50 AM, Mimi Zohar wrote: > >> I did have a question about the 'd-ng | sig | sig' template. Is that an > >> error or could a file be signed with e.g. both RSA-2048 and RSA-3072? > >> > >> Etc. You can see where I'm going - precise rules for an IMA log verifier. > > The "sig" field is the original IMA signature, stored as an extended > > attribute. If/when IMA fs-verity support is added, that signature > > would require defining new digest and signature field types. A > > template with two "sig" fields doesn't make sense. > > We cannot prevent an attacker from creating the custom template 'd-ng | > sig | sig', nor can we prevent an attacker from sending such a log to a > verifier. Thus, we have to specify to a verifier what logs are valid > and what logs should be rejected and flagged as an attack. That's correct. A user can define a template with any field he wants. Whether the template is acceptable, it depends on the verifier and on his requirements. If the template contains all fields necessary for the verification, that should be fine even if that template contains redundant information. If there are inconsistencies, the verifier would simply return an error as verification result. Defining a specification for which combinations are legitimate would definitely help. > There are 8-9 different possible IMA log fields, and we have to assume > the attacker will corrupt any or all of them. Template data is protected by the TPM. Any corruption can be detected by comparing the quoted PCRs with the PCRs calculated from the template digest. What it remains to be done is to include the template name in the calculation of the template digest. Roberto
