From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Matthew Garrett <mjg59@google.com>, linux-integrity@vger.kernel.org
Cc: Mikhail Kurinnoi <viewizard@viewizard.com>
Subject: Re: RFC: Make it practical to ship EVM signatures
Date: Thu, 28 Sep 2017 16:12:40 -0400 [thread overview]
Message-ID: <1506629560.5691.33.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170927221653.11219-1-mjg59@google.com>
Hi Matthew,
[Cc'ing Mikhail Kurinnoi]
On Wed, 2017-09-27 at 15:16 -0700, Matthew Garrett wrote:
> These are basically untested, but I'd like to get some feedback on the
> problem I'm trying to solve here. We'd like to be able to ship packages
> with verifiable security xattrs, but right now EVM makes this difficult
> due to its requirement that the inode number be encoded in the hmac. This
> patchset is intended to make it possible to protect a subset of metadata
> rather than all of it, and also to permit using EVM digital signatures in
> a similar way to how IMA digital signatures can be used now (ie, protecting
> the metadata using public/private crypto rather than having a local
> symmetric key and generating the HMACs locally). The expected workflow is:
>
> 1) During package build or mirroring process, appropriate security metadata
> is added (IMA hash, selinux label, etc)
> 2) An EVM digital signature is generated based purely on the security
> metadata present during the build or mirroring process
> 3) IMA is extended to allow it to force EVM validation during appraisal even
> if no symmetric EVM key has been added, which allows IMA appraisal to
> appraise not only the IMA hash but also the additional metadata
> 4) If EVM is never enabled, binaries are purely validated using the EVM
> digital signatures and are not transitioned to using HMACs
> 5) If EVM is desired, userland can set the set of metadata to be incorporated
> into the EVM HMAC before enabling EVM
Earlier this year there were discussions on defining a portable EVM
signature, that could be included in software packages.
The reason for including as much metadata as possible in the HMAC is
to limit cut & paste attacks. For this reason, the portable data is
only used in transmission, not on disk.
A new EVM type is defined that does not convert the EVM signature to
an HMAC.
Mikhail's patches:
https://sourceforge.net/p/linux-ima/mailman/linux-ima-user/thread/2017
0113072602.4ffaa30a@totoro/
I've been negligent in reviewing and testing his patches. Perhaps
they will meet your needs.
Mimi
next prev parent reply other threads:[~2017-09-28 20:12 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-27 22:16 RFC: Make it practical to ship EVM signatures Matthew Garrett
2017-09-27 22:16 ` [PATCH 1/6] IMA: Allow EVM validation on appraisal even without a symmetric key Matthew Garrett
2017-10-01 2:08 ` Mimi Zohar
2017-10-02 17:02 ` Matthew Garrett
2017-10-02 19:41 ` Mimi Zohar
2017-09-27 22:16 ` [PATCH 2/6] EVM: Add infrastructure for making EVM fields optional Matthew Garrett
2017-09-27 22:16 ` [PATCH 3/6] EVM: Allow userland to override the default EVM attributes Matthew Garrett
2017-09-27 22:16 ` [PATCH 4/6] EVM: Add an hmac_ng xattr format Matthew Garrett
2017-09-27 22:16 ` [PATCH 5/6] EVM: Write out HMAC xattrs in the new format Matthew Garrett
2017-09-27 22:16 ` [PATCH 6/6] EVM: Add a new digital signature format Matthew Garrett
2017-09-28 20:12 ` Mimi Zohar [this message]
2017-09-28 21:13 ` RFC: Make it practical to ship EVM signatures Matthew Garrett
2017-09-29 0:53 ` Mimi Zohar
2017-09-29 18:09 ` Matthew Garrett
2017-09-29 19:02 ` Mimi Zohar
2017-09-29 19:17 ` Matthew Garrett
2017-09-29 20:01 ` Mimi Zohar
2017-09-29 20:09 ` Matthew Garrett
2017-10-01 2:36 ` Mimi Zohar
2017-10-02 17:09 ` Matthew Garrett
2017-10-02 19:54 ` Mimi Zohar
[not found] ` <CACdnJutYw7Pgh-EwWuwp9Wz+5KzoreZVr+c6UV30zC__8FZSVA@mail.gmail.com>
[not found] ` <1506974574.5691.304.camel@linux.vnet.ibm.com>
2017-10-02 20:07 ` Matthew Garrett
2017-10-09 17:51 ` Mimi Zohar
2017-10-09 17:59 ` Matthew Garrett
2017-10-09 18:15 ` Mimi Zohar
2017-10-09 18:18 ` Matthew Garrett
2017-10-09 18:40 ` Mimi Zohar
[not found] ` <20171009232314.545de76a@totoro>
[not found] ` <1507583449.3748.46.camel@linux.vnet.ibm.com>
[not found] ` <20171010003326.6409ae23@totoro>
2017-10-09 21:40 ` Mimi Zohar
2017-10-09 23:10 ` Mikhail Kurinnoi
2017-10-10 19:07 ` Mimi Zohar
2017-10-12 23:09 ` Dmitry Kasatkin
2017-10-18 19:48 ` Dmitry Kasatkin
2017-10-18 20:30 ` Mimi Zohar
2017-10-18 20:37 ` Dmitry Kasatkin
2017-10-18 21:02 ` Mikhail Kurinnoi
2017-10-18 21:07 ` Mimi Zohar
2017-10-19 10:14 ` Dmitry Kasatkin
2017-10-19 11:43 ` Mimi Zohar
2017-10-19 17:08 ` Matthew Garrett
2017-10-19 18:38 ` Dmitry Kasatkin
2017-10-19 10:36 ` Dmitry Kasatkin
2017-10-19 11:45 ` Mimi Zohar
2017-10-02 14:53 ` Roberto Sassu
2017-10-02 8:55 ` 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=1506629560.5691.33.camel@linux.vnet.ibm.com \
--to=zohar@linux.vnet.ibm.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 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).