linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"containers@lists.linux-foundation.org" 
	<containers@lists.linux-foundation.org>,
	"linux-security-module@vger.kernel.org" 
	<linux-security-module@vger.kernel.org>
Cc: "zohar@linux.ibm.com" <zohar@linux.ibm.com>,
	"stefanb@linux.vnet.ibm.com" <stefanb@linux.vnet.ibm.com>,
	"sunyuqiong1988@gmail.com" <sunyuqiong1988@gmail.com>,
	"mkayaalp@cs.binghamton.edu" <mkayaalp@cs.binghamton.edu>,
	"dmitry.kasatkin@gmail.com" <dmitry.kasatkin@gmail.com>,
	"serge@hallyn.com" <serge@hallyn.com>,
	"jmorris@namei.org" <jmorris@namei.org>,
	"christian@brauner.io" <christian@brauner.io>,
	Silviu Vlasceanu <Silviu.Vlasceanu@huawei.com>,
	Roberto Sassu <roberto.sassu@huawei.com>
Subject: RE: [RFC PATCH 00/30] ima: Introduce IMA namespace
Date: Fri, 21 Aug 2020 15:13:01 +0000	[thread overview]
Message-ID: <401a2f36149f450291d1742aeb6c2260@huawei.com> (raw)
In-Reply-To: <1597767571.3898.15.camel@HansenPartnership.com>

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


  reply	other threads:[~2020-08-21 15:14 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <N>
2012-11-22 11:54 ` [PATCH 1/2] fs/buffer.c: do not inline exported function Yan Hong
2012-11-22 11:54   ` [PATCH 2/2] fs/buffer.c: remove redundant initialization in alloc_page_buffers() Yan Hong
2014-02-12 10:06 ` [PATCH v2] NFSv4.1: new layout stateid can not be overwrite by one out of date shaobingqing
2014-02-12 12:34   ` Trond Myklebust
2014-02-17  7:08 ` [PATCH v3] " shaobingqing
2014-02-17 16:46   ` Trond Myklebust
2014-11-04  1:47 ` [PATCH usb v4 0/2] fixes on resource check varkabhadram
2014-11-04  1:47   ` [PATCH usb v4 1/2] host: uhci-platform: fix NULL pointer dereference on resource varkabhadram
2014-11-04  1:47   ` [PATCH usb v4 2/2] host: ehci-sead3: " varkabhadram
2020-08-18 15:20 ` [RFC PATCH 00/30] ima: Introduce IMA namespace krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 01/30] ima: Introduce ima namespace krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 02/30] ima: Add a list of the installed ima namespaces krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 03/30] ima: Bind ima namespace to the file descriptor krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 04/30] ima: Add ima policy related data to the ima namespace krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 05/30] ima: Add methods for parsing ima policy configuration string krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 06/30] ima: Add ima namespace to the ima subsystem APIs krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 07/30] ima: Extend the APIs in the integrity subsystem krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 08/30] ima: Add integrity inode related data to the ima namespace krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 09/30] ima: Enable per ima namespace policy settings krzysztof.struczynski
2020-08-18 15:53   ` [RFC PATCH 00/30] ima: Introduce IMA namespace Christian Brauner
2020-08-21 15:18     ` Krzysztof Struczynski
2020-08-18 16:19   ` James Bottomley
2020-08-21 15:13     ` Krzysztof Struczynski [this message]
2020-09-02 18:53       ` Mimi Zohar
2020-09-04 14:06         ` Dr. Greg
2020-09-14 12:05         ` Krzysztof Struczynski
2020-08-18 16:49   ` Christian Brauner
2020-08-21 15:37     ` Krzysztof Struczynski
2020-09-02 19:54     ` Mimi Zohar
2020-09-06 17:14       ` Dr. Greg
     [not found]         ` <CAKrSGQR3Pw=Rad2RgUuCHqr0r2Nc6x2nLoo2cVAkD+_8Vbmd7A@mail.gmail.com>
2020-09-08 14:03           ` Mimi Zohar
2020-09-14 12:07             ` Krzysztof Struczynski
2020-10-19  9:30             ` Krzysztof Struczynski
2020-10-25 15:00               ` Dr. Greg
2020-09-09 10:11           ` Dr. Greg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=401a2f36149f450291d1742aeb6c2260@huawei.com \
    --to=krzysztof.struczynski@huawei.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=Silviu.Vlasceanu@huawei.com \
    --cc=christian@brauner.io \
    --cc=containers@lists.linux-foundation.org \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=jmorris@namei.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mkayaalp@cs.binghamton.edu \
    --cc=roberto.sassu@huawei.com \
    --cc=serge@hallyn.com \
    --cc=stefanb@linux.vnet.ibm.com \
    --cc=sunyuqiong1988@gmail.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).