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]
Date:   Tue, 18 Aug 2020 09:19:31 -0700
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     krzysztof.struczynski@...wei.com, linux-integrity@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        containers@...ts.linux-foundation.org,
        linux-security-module@...r.kernel.org
Cc:     zohar@...ux.ibm.com, stefanb@...ux.vnet.ibm.com,
        sunyuqiong1988@...il.com, mkayaalp@...binghamton.edu,
        dmitry.kasatkin@...il.com, serge@...lyn.com, jmorris@...ei.org,
        christian@...uner.io, silviu.vlasceanu@...wei.com,
        roberto.sassu@...wei.com
Subject: Re: [RFC PATCH 00/30] ima: Introduce IMA namespace

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 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.

James

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ