RE: Spec needed for ima-modsig template

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Ken Goldman [mailto:kgold@xxxxxxxxxxxxx]
> Sent: Tuesday, January 7, 2020 4:41 PM
> To: Roberto Sassu <roberto.sassu@xxxxxxxxxx>; Mimi Zohar
> <zohar@xxxxxxxxxxxxx>; Linux Integrity <linux-integrity@xxxxxxxxxxxxxxx>;
> Ken Goldman <kgoldman@xxxxxxxxxx>; Silviu Vlasceanu
> <Silviu.Vlasceanu@xxxxxxxxxx>
> Subject: Re: Spec needed for ima-modsig template
> 
> On 1/7/2020 3:53 AM, Roberto Sassu wrote:
> > Defining a specification for which combinations
> > are legitimate would definitely help.
> 
> That's my goal.
> 
> >> 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.
> 
> An attacker can create a custom template or even modify the IMA source
> so that the hashes and PCRs match.  Then they send the malformed log to
> the verifier to try to exploit a vulnerability.

Modifying the IMA source can be excluded from possible attacks. The
modified kernel can be detected from the BIOS event log.

> E.g., the custom template 'd-ng|d-ng| ...' repeated 1,000,000,000 times.

Currently, the number of fields in a template format can be at most
IMA_TEMPLATE_NUM_FIELDS_MAX. I don't know if repeating the same
template field could introduce more risks.

> > What it remains to be done is to include the template name in the
> > calculation of the template digest.
> 
> There's a backward compatibility issue for old templates.  Is it
> feasible for new templates and new names - start creating tags and
> include them in the template data so they gets hashed?

I would suggest the following formats (without and with tags), to make
it easier for the parsers to distinguish between the old and the new format.

Assuming that the template format is 'field#0|...|field#N', the binary
format of each measurement entry without tags becomes:

<PCR><template digest><total len>\0<template name len><template name>
                                                                             <len#0><data#0>
                                                                             <len#N><data#N>

Template name can be one of the defined templates or 'field#0|...|field#N',
if the user specifies a custom format.

The binary format with tags becomes:

<PCR><template digest><total len>\0<tag#0><len#0><data#0>
                                                                             <tag#N><len#N><data#N>

Tag definition must be available for user space applications.

The \0 after <total len> allows parsers to distinguish between the old and
the new format. If there is no \0, parsers assume that <total len> is the
template name length of the old format.

For the new format, template digest is calculated on data after <total len>.

Roberto




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux