Re: [PATCH] security: Fix IMA Kconfig for dependencies on ARM64

[James Bottomley]

On Mon, 2018-03-12 at 17:53 -0400, Mimi Zohar wrote:
> 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.

I don't think this is quite the correct characterisation. ÂIn principle
the kernel could also touch the files before IMA is loaded. ÂHowever,
we know from the way the kernel operates that it doesn't. ÂWe basically
trust that the kernel measurement tells us this. ÂThe same thing can be
made to apply to the initrd.

The key question is not whether the component could theoretically
access the files but whether it actually does so.

> ÂÂÂÂ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,

If I don't trust the initrd then I also can't really make much of IMA
measurements because the chain of custody is broken. ÂThe assertion
that the initrd has to be part of the chain of custody is really a
statement of the current position. ÂTherefore if the initrd is part of
that chain, then we don't have to start IMA at kernel init, we can
start it at initrd pivot_root. Â(or to put it in simple terms: IMA
measurements of the root filesystem, even if they begin at kernel init,
cannot make up for a malicious initrd because the damage will already
have been done before we pivot to the real root).

In theory the build device shouldn't be suspect because it was measured and appraised before I built my initrd on it.

>  but after that,
> ÂÂÂÂthe attestation server has no way to trust a reported initramfs
> ÂÂÂÂmeasurement.

This is more a reflection of problems in the current attestation
architecture and measurement gaps we have. ÂWe certainly know what the
initrd measurement should be when we create it, so the expected value
can be communicated to the attestation server when the initrd is built.

Conversely, if the attestation server doesn't measure the initrd this
is a current gap in the attestation of the custody chain because any
problem with the initrd would go undetected.

James