RE: [RFC PATCH 00/30] ima: Introduce IMA namespace

[Krzysztof Struczynski]

> From: James Bottomley [mailto:James.Bottomley@xxxxxxxxxxxxxxxxxxxxx]
> On Tue, 2020-08-18 at 17:20 +0200, krzysztof.struczynski@xxxxxxxxxx
> wrote:
> > The measurement list remains global, with the assumption that there
> > is only one TPM in the system. Each IMA namespace has a unique ID,
> > that allows to track measurements per IMA namespace. Processes in one
> > namespace, have access only to the measurements from that namespace.
> > The exception is made for the initial IMA namespace, whose processes
> > have access to all entries.
> 
> So I think this can work in the use case where the system owner is
> responsible for doing the logging and attestation and the tenants just
> trust the owner without requiring an attestation.  However, in a multi-
> tenant system you need a way for the attestation to be per-container
> (because the combined list of who executed what would be a security
> leak between tenants).  Since we can't virtualise the PCRs without
> introducing a vtpm this is going to require a vtpm infrastructure like
> that used for virtual machines and then we can do IMA logging per
> container.

I agree and wonder if we should decouple the attestation trust model,
which depends on the specific use case (e.g. multi/single tenant,
public/private cloud), from the IMA logic of linking the measurements to
the container. Indeed, attestation from within the container might require
anchoring to a vTPM/vPCR and the current measurement tagging mechanism can
support several ways of anchoring them to a (virtual) root of trust.

> I don't think the above has to be in your first patch set, we just have
> to have an idea of how it could be done to show that nothing in this
> patch set precludes a follow on from doing this.

Given that virtualizing trust anchors seems like a separate problem in
which industry consensus is not easy to reach for all use cases, an
anchoring mechanism should probably be a separate IMA feature.

> 
> James