Message-Id: <1569600489.10820.77.camel@linux.ibm.com>
Date:   Fri, 27 Sep 2019 12:08:09 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     linux-security-module <linux-security-module@...r.kernel.org>,
        linux-integrity <linux-integrity@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] integrity subsystem updates for v5.4

On Mon, 2019-09-16 at 18:13 -0400, Mimi Zohar wrote:
> On Mon, 2019-09-16 at 13:38 -0700, Linus Torvalds wrote:
> > On Wed, Sep 11, 2019 at 2:29 PM Mimi Zohar <zohar@...ux.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.

My writing tends to be brief, hopefully concise.  I assume if you had
further questions you would have asked.

This pull request contained a lot of refactoring of the existing
appended signature verification code, so that IMA could retain the
existing framework of calculating the file hash once, storing it in
the IMA measurement list and extending the TPM, verifying the file's
integrity based on a file hash or signature (eg. xattrs), and adding
an audit record containing the file hash, all based on policy.  (The
IMA support for appended signatures patch set was posted and reviewed
11 times.)

The support for appended signature paves the way for adding other
signature verification methods, such as fs-verity, based on a single
system-wide policy.  The file hash used for verifying the signature
and the signature, itself, can be included in the IMA measurement
list.

Originally, IMA & EVM were limited to local kernel file systems, based
on i_version, but have been extended to support filesystems that don't
support i_version and for FUSE.  There are additional discussions for
extending IMA to support remote filesystems (eg. IETF NFS draft).  IMA
by itself isn't enough, since the remote file isn't pinned in memory,
but will need to be dependent on fs-verity.

Nayna Jain re-posted a patch set (v6) titled "powerpc: Enabling IMA
arch specific secure boot policies".  The changes are based on Michael
Ellerman's review.

thanks,

Mimi

Powered by blists - more mailing lists