All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roberto Sassu <roberto.sassu@huawei.com>
To: Ken Goldman <kgold@linux.ibm.com>,
	Mimi Zohar <zohar@linux.ibm.com>,
	Linux Integrity <linux-integrity@vger.kernel.org>,
	Ken Goldman <kgoldman@us.ibm.com>,
	Silviu Vlasceanu <Silviu.Vlasceanu@huawei.com>
Subject: RE: Spec needed for ima-modsig template
Date: Tue, 7 Jan 2020 17:53:15 +0000	[thread overview]
Message-ID: <191aee7d3b5c491ebd0a19850563cb5d@huawei.com> (raw)
In-Reply-To: <0cdf74d5-671f-7958-c74f-6dc82bf3077e@linux.ibm.com>

> -----Original Message-----
> From: Ken Goldman [mailto:kgold@linux.ibm.com]
> Sent: Tuesday, January 7, 2020 4:41 PM
> To: Roberto Sassu <roberto.sassu@huawei.com>; Mimi Zohar
> <zohar@linux.ibm.com>; Linux Integrity <linux-integrity@vger.kernel.org>;
> Ken Goldman <kgoldman@us.ibm.com>; Silviu Vlasceanu
> <Silviu.Vlasceanu@huawei.com>
> 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

      reply	other threads:[~2020-01-07 17:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-02 20:10 Spec needed for ima-modsig template Ken Goldman
2020-01-02 20:25 ` Mimi Zohar
2020-01-02 22:24   ` Ken Goldman
2020-01-02 23:22     ` Mimi Zohar
2020-01-03 18:27       ` Ken Goldman
2020-01-03 18:57         ` Spec needed for ima-buf template Ken Goldman
2020-01-03 19:25           ` Spec needed for ima-buf template - missing hash algorithm Ken Goldman
2020-01-04 23:32         ` Spec needed for ima-modsig template Mimi Zohar
2020-01-06 14:27           ` Ken Goldman
2020-01-06 17:18             ` Mimi Zohar
2020-01-06 14:36           ` Ken Goldman
2020-01-06 15:50             ` Mimi Zohar
2020-01-06 16:01               ` Ken Goldman
2020-01-06 16:55                 ` Mimi Zohar
2020-01-07  8:53                 ` Roberto Sassu
2020-01-07 15:40                   ` Ken Goldman
2020-01-07 17:53                     ` Roberto Sassu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=191aee7d3b5c491ebd0a19850563cb5d@huawei.com \
    --to=roberto.sassu@huawei.com \
    --cc=Silviu.Vlasceanu@huawei.com \
    --cc=kgold@linux.ibm.com \
    --cc=kgoldman@us.ibm.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.