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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <401a2f36149f450291d1742aeb6c2260@huawei.com>
Date:   Fri, 21 Aug 2020 15:13:01 +0000
From:   Krzysztof Struczynski <krzysztof.struczynski@...wei.com>
To:     James Bottomley <James.Bottomley@...senPartnership.com>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "containers@...ts.linux-foundation.org" 
        <containers@...ts.linux-foundation.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>
CC:     "zohar@...ux.ibm.com" <zohar@...ux.ibm.com>,
        "stefanb@...ux.vnet.ibm.com" <stefanb@...ux.vnet.ibm.com>,
        "sunyuqiong1988@...il.com" <sunyuqiong1988@...il.com>,
        "mkayaalp@...binghamton.edu" <mkayaalp@...binghamton.edu>,
        "dmitry.kasatkin@...il.com" <dmitry.kasatkin@...il.com>,
        "serge@...lyn.com" <serge@...lyn.com>,
        "jmorris@...ei.org" <jmorris@...ei.org>,
        "christian@...uner.io" <christian@...uner.io>,
        Silviu Vlasceanu <Silviu.Vlasceanu@...wei.com>,
        Roberto Sassu <roberto.sassu@...wei.com>
Subject: RE: [RFC PATCH 00/30] ima: Introduce IMA namespace

> From: James Bottomley [mailto:James.Bottomley@...senPartnership.com]
> On Tue, 2020-08-18 at 17:20 +0200, krzysztof.struczynski@...wei.com
> 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