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

[Safford, David (GE Global Research, US)]

> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley at HansenPartnership.com]
> Sent: Monday, March 12, 2018 8:07 PM
> To: Mimi Zohar <zohar at linux.vnet.ibm.com>; Jiandi An
> <anjiandi at codeaurora.org>; Jason Gunthorpe <jgg at ziepe.ca>
> Cc: dmitry.kasatkin at gmail.com; jmorris at namei.org; serge at hallyn.com;
> linux-integrity at vger.kernel.org; linux-ima-devel at lists.sourceforge.net;
> linux-ima-user at lists.sourceforge.net; linux-security-
> module at vger.kernel.org; linux-kernel at vger.kernel.org; Safford, David (GE
> Global Research, US) <david.safford at ge.com>
> Subject: EXT: Re: [PATCH] security: Fix IMA Kconfig for dependencies on
> ARM64
> 
> On Mon, 2018-03-12 at 19:30 -0400, Mimi Zohar wrote:
> > On Mon, 2018-03-12 at 15:30 -0700, James Bottomley wrote:
> > >
> > > On Mon, 2018-03-12 at 17:53 -0400, Mimi Zohar wrote:
> > [...]
> > >
> > > >
> > > > - 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.
> >
> > With the builtin "tcb" policy, IMA-measurement is enabled from the
> > very beginning. Â Afterwards, the system can transition to a custom
> > policy based on finer grain LSM labels, which aren't available on
> > boot.
> >
> > >
> > > The key question is not whether the component could theoretically
> > > access the files but whether it actually does so.
> >
> > As much as you might think you know what is included in the initramfs,
> > IMA-measurement is your safety net, including everything accessed in
> > the TCB.
> 
> The initrd *is* part of the Trusted Computing Base because it's part of the
> boot custody chain. Â That's really my point. Â If I don't know what's in my initrd,
> I've broken the chain there and IMA can't fix it.
> 
> James

That's exactly the point - how do you know what's in your initrd?
The initrd is normally built on the possibly compromised system in question.
It's not signed as a whole by someone trusted. How can the attestation
server say a given hash of the initrd as a whole is good?

If IMA is running from the very start, it can at least measure (and eventually appraise)
every individual file in the initrd. Given this more detailed measurement list, the
attestation server can verify all the components in the initrd, even when it is
assembled on the untrusted system.

On many embedded systems, there is no initrd, and IMA has to start measuring
and appraising immediately, anyway.

Perhaps there is a use case where there is a known set of initrd images, 
and so the bootloader's measurement of the initrd is sufficient for verification.
I've not run into that situation yet. If you want an option for this use case, 
that's fine, (I'm all for choice) but it should not be the default for IMA.

dave
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ¥Šwÿº{.nÇ+‰·¥Š{±þÇœº¸­Ëù¨vé^þ)í…æèw*jg¬±¨¶‰šŽŠÝ¢jÿ¾«þG«éÿ¢¸¢·¦j:+v‰¨ŠwèjØm¶Ÿÿþø¯ù®w¥þŠàþf£¢·hšâúÿ†Ù¥