linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Ken Goldman <kgold@linux.ibm.com>,
	Linux Integrity <linux-integrity@vger.kernel.org>,
	Ken Goldman <kgoldman@us.ibm.com>,
	Roberto Sassu <roberto.sassu@huawei.com>
Subject: Re: Spec needed for ima-modsig template
Date: Mon, 06 Jan 2020 11:55:53 -0500	[thread overview]
Message-ID: <1578329753.5222.59.camel@linux.ibm.com> (raw)
In-Reply-To: <7415a1ba-7fa9-4e86-f143-a3bc1bfdc80f@linux.ibm.com>

On Mon, 2020-01-06 at 11:01 -0500, Ken Goldman wrote:
> 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.

There is only one security.ima extended attribute per file, at least
for the time being until IMA namespacing.  That would imply both "sig"
fields would have to be exactly the same.

Mimi

> 
> I.e., the verifier cannot assume that it will only receive logs that 
> make sense.  A secure parser has to handle any cleverly malformed event log.
> 
> There are 8-9 different possible IMA log fields, and we have to assume 
> the attacker will corrupt any or all of them.


  reply	other threads:[~2020-01-06 16:56 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 [this message]
2020-01-07  8:53                 ` Roberto Sassu
2020-01-07 15:40                   ` Ken Goldman
2020-01-07 17:53                     ` Roberto Sassu

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=1578329753.5222.59.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=kgold@linux.ibm.com \
    --cc=kgoldman@us.ibm.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=roberto.sassu@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).