On Tue, 2018-03-13 at 12:57 +0000, Safford, David (GE Global Research,
US) wrote:

quoted

-----Original Message-----
From: James Bottomley [mailto:James.Bottomley at HansenPartnership.com
]
Sent: Monday, March 12, 2018 8:07 PM
To: Mimi Zohar <redacted>; Jiandi An

[...]

quoted

quoted

quoted

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.

The point of deploying security measures is to make sure my system
isn't compromised. ?I realise the institutional view is "we didn't
build the initrd" and my individual view is well, I built my own kernel
as well, so what's the difference? ?But the initrd in both models is
still part of the chain.

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?

I trust myself. ?I can get the hash at build time. ?In the same way as
I sign my own kernel at build time for secure boot.

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.

Actually, we seem to have wandered away from the main concern which was
trying to select built in TPM drivers. ?What about a compromise: we
already get the boot loader to do measurements and PCR extensions using
the BIOS TPM driver, there's no reason why we can't do the same in the
early kernel until a real TPM driver is found. ?That way IMA would have
no dependency on any built in TPM driver ... is that an acceptable
compromise to everyone?

James

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html