[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1520891598.3547.190.camel@linux.vnet.ibm.com>
Date: Mon, 12 Mar 2018 17:53:18 -0400
From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
To: James Bottomley <James.Bottomley@...senPartnership.com>,
Jiandi An <anjiandi@...eaurora.org>,
Jason Gunthorpe <jgg@...pe.ca>
Cc: dmitry.kasatkin@...il.com, jmorris@...ei.org, serge@...lyn.com,
linux-integrity@...r.kernel.org,
linux-ima-devel@...ts.sourceforge.net,
linux-ima-user@...ts.sourceforge.net,
linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, David Safford <david.safford@...com>
Subject: Re: [PATCH] security: Fix IMA Kconfig for dependencies on ARM64
On Fri, 2018-03-09 at 09:11 -0800, James Bottomley wrote:
> On Thu, 2018-03-08 at 12:42 -0600, Jiandi An wrote:
> [...]
> > I'm no expert on IMA and its driver. James, will you be kind enough
> > to look into overhauling the IMA driver to not measure until after
> > initrd phase if that's the consensus on resolving this?
>
> I'll add it to my todo list.
>
> Since my TPM 2.0 test environment is a VM with a tpm that has a network
> connection to an emulator on my host, it's impossible to set it up so
> that it's built in (because you need the network config before you init
> the TPM) so I might accelerate if I suddenly need to debug IMA issues
> in this configuration.
There are a number of different issues being discussed.
- When IMA is enabled, unlike some other TPM device drivers, the TPM
2.0 is not forced to be builtin.
This is addressed by Jiandi's patch.
- Jason's comment questioning having Kconfig force the TPM to be
builtin.
Using Kconfig to force the TPM to be builtin is not required, but
helpful. Users interested in IMA-measurement could configure the TPM
as builtin themselves. Without the TPM builtin, IMA goes into TPM-
bypass mode.
Extending a TPM with IMA measurements, which was not builtin, but
loaded at some unspecified point in time, changes the existing meaning
of the IMA-measurement list.
- This use case, when the TPM is not builtin and unavailable before
IMA is initialized.
I would classify this use case as an IMA testing/debugging
environment, when it cannot, for whatever reason, be builtin the
kernel or initialized before IMA.
>From Dave Safford:
For the TCG chain of trust to have any meaning, all files have to
be measured and extended into the TPM before they are accessed. If
the TPM driver is loaded after any unmeasured file, the chain is
broken, and IMA is useless for any use case or any threat model.
While the initramfs may be measured by the bootloader, there are
two problems:
1. IMA has no way of knowing if the kernel or initramfs has
accessed any unmeasured files before TPM driver loading and IMA
initialization.
2. Even if we can somehow guarantee that nothing outside the
initramfs has been accessed prior to IMA initialization, it is
difficult if not impossible for the attestation server to know what
a good initramfs measurement should be, as the initramfs is built
on the suspect device in the first place. We can sort of trust the
initramfs measurement in the reference manifest, but after that,
the attestation server has no way to trust a reported initramfs
measurement.
Mimi
Powered by blists - more mailing lists