Thread (21 messages) 21 messages, 5 authors, 2020-09-14

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

From: Mimi Zohar <zohar@linux.ibm.com>
Date: 2020-09-02 18:53:51
Also in: linux-integrity, lkml

Possibly related (same subject, not in this thread)

On Fri, 2020-08-21 at 15:13 +0000, Krzysztof Struczynski wrote:
quoted
From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
On Tue, 2020-08-18 at 17:20 +0200, krzysztof.struczynski@huawei.com
wrote:
quoted
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.
quoted
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.
Other trust anchors for "trusted keys" has been discussed, but I wasn't
aware of any discussion about other trust anchors for the IMA
measurement list.  The IMA measurement list is very much tied to a TPM.

Including container measurements in the host measurement list, will
unnecessarily cause the host measurement list to grow.  The decision of
what should and shouldn't be included in the host measurement list
shouldn't be defined by the container.

Mimi


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help