All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Matthew Garrett <mjg59@google.com>
Cc: linux-integrity <linux-integrity@vger.kernel.org>,
	Dmitry Kasatkin <dmitry.kasatkin@huawei.com>,
	Mikhail Kurinnoi <viewizard@viewizard.com>
Subject: Re: [PATCH] EVM: Add support for portable signature format
Date: Thu, 19 Oct 2017 13:44:31 -0400	[thread overview]
Message-ID: <1508435071.3268.36.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <CACdnJuuaLJ0g0-o567YsEU8pxs4c1xMZLU2viU6FFG6_t9uh3Q@mail.gmail.com>


> >> Admins should note that creating portable signatures that do not include
> >> the security.ima xattr would allow these signatures to be applied to any
> >> file with the same owners and security labels, which would allow
> >> subversion of EVM's security guarantees. The kernel does not attempt to
> >> enforce this.
> >
> > As much as possible IMA and EVM should work independently of each
> > other.  But in this case, I think we need to blur the lines a bit.
> >
> > Currently, before writing a new security.evm value, the existing
> > security.evm value is verified.  To do this it has to read the
> > security xattrs to calculate the hash/hmac.  How hard would it really
> > be to verify that a security.ima xattr exists, before writing this new
> > EVM signature?  How hard would it be to make sure that security.ima is
> > included in the calculation on verification?
> 
> I don't think it would be especially hard to ensure that security.ima
> is present if the portable digsig format is used, but as you say it
> would blur the lines a little.

I'd rather err on the side of caution, preventing an unnecessary
possible attack.  In this case, I think it is warranted.

      reply	other threads:[~2017-10-19 17:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-18 18:01 [PATCH] EVM: Add support for portable signature format Matthew Garrett
2017-10-19 11:02 ` Dmitry Kasatkin
2017-10-19 11:55   ` Mikhail Kurinnoi
2017-10-19 12:00   ` Mimi Zohar
2017-10-19 15:11     ` Dmitry Kasatkin
2017-10-19 17:11       ` Matthew Garrett
2017-10-19 18:02         ` Dmitry Kasatkin
2017-10-19 18:13           ` Dmitry Kasatkin
2017-10-19 18:15           ` Matthew Garrett
2017-10-19 18:50             ` Dmitry Kasatkin
2017-10-19 12:52 ` Mimi Zohar
2017-10-19 17:09   ` Matthew Garrett
2017-10-19 17:44     ` Mimi Zohar [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=1508435071.3268.36.camel@linux.vnet.ibm.com \
    --to=zohar@linux.vnet.ibm.com \
    --cc=dmitry.kasatkin@huawei.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=mjg59@google.com \
    --cc=viewizard@viewizard.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.