From: Mimi Zohar <zohar@linux.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-security-module <linux-security-module@vger.kernel.org>,
linux-integrity <linux-integrity@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] integrity subsystem updates for v5.4
Date: Mon, 16 Sep 2019 18:13:02 -0400 [thread overview]
Message-ID: <1568671982.4975.145.camel@linux.ibm.com> (raw)
In-Reply-To: <CAHk-=whuzoK+sP+feizU520p7ChHqdX8pmwyCnnKTyUNJKngZA@mail.gmail.com>
On Mon, 2019-09-16 at 13:38 -0700, Linus Torvalds wrote:
> On Wed, Sep 11, 2019 at 2:29 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > The major feature in this pull request is IMA support for measuring
> > and appraising appended file signatures. In addition are a couple of
> > bug fixes and code cleanup to use struct_size().
>
> How is the file signature any different from (and/or better than) the
> fs-verity support?
>
> The fs-verity support got fairly extensively discussed, and is
> apparently going to actually be widely used by Android, and it an
> independent feature of any security model.
>
> What does the IMA version bring to the table?
IMA currently defines a system wide policy for measuring, verifying a
file's integrity (both mutable/immutable files) against known good
values, and adding audit records containing the file hashes. The
policy isn't hard coded in the kernel, allowing people/companies to
configure it as desired for their specific use case.
Support for appended signatures already exists in the kernel for
kernel modules. This pull request adds IMA support for appended
signatures in order to verify the kexec kernel image on OpenPOWER, as
part of Secure and Trusted boot enablement. This would allow distros
to sign kernel images similar to how they currently sign kernel
modules.
IMA verifies file signatures up front, before allowing access to the
file. fs-verity verifies the signature of the Merkle tree (and other
info), but does not verify the file data at the time of first use.
There are pros and cons to each of these approaches.
Mimi
next prev parent reply other threads:[~2019-09-16 22:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-11 21:29 [GIT PULL] integrity subsystem updates for v5.4 Mimi Zohar
2019-09-16 20:38 ` Linus Torvalds
2019-09-16 22:13 ` Mimi Zohar [this message]
2019-09-27 16:08 ` Mimi Zohar
2019-09-28 3:00 ` pr-tracker-bot
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=1568671982.4975.145.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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).