linux-kernel - Re: [RFC 08/20] ima: Move measurement list related variables into ima

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 for Android: free password hash cracker in your pocket

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

Message-ID: <39e43a4829b86b5a87bc082628cc6f45d4d8c899.camel@linux.ibm.com>
Date:   Thu, 02 Dec 2021 12:44:23 -0500
From:   James Bottomley <jejb@...ux.ibm.com>
To:     Stefan Berger <stefanb@...ux.ibm.com>,
        linux-integrity@...r.kernel.org
Cc:     zohar@...ux.ibm.com, serge@...lyn.com,
        christian.brauner@...ntu.com, containers@...ts.linux.dev,
        dmitry.kasatkin@...il.com, ebiederm@...ssion.com,
        krzysztof.struczynski@...wei.com, roberto.sassu@...wei.com,
        mpeters@...hat.com, lhinds@...hat.com, lsturman@...hat.com,
        puiterwi@...hat.com, jamjoom@...ibm.com,
        linux-kernel@...r.kernel.org, paul@...l-moore.com, rgb@...hat.com,
        linux-security-module@...r.kernel.org, jmorris@...ei.org
Subject: Re: [RFC 08/20] ima: Move measurement list related variables into
 ima_namespace

On Thu, 2021-12-02 at 11:45 -0500, Stefan Berger wrote:
> On 12/2/21 11:29, James Bottomley wrote:
> > On Thu, 2021-12-02 at 08:41 -0500, Stefan Berger wrote:
> > > On 12/2/21 07:46, James Bottomley wrote:
> > > > On Tue, 2021-11-30 at 11:06 -0500, Stefan Berger wrote:
> > > > > Move measurement list related variables into the
> > > > > ima_namespace.
> > > > > This
> > > > > way a
> > > > > front-end like SecurityFS can show the measurement list
> > > > > inside an
> > > > > IMA
> > > > > namespace.
> > > > > 
> > > > > Implement ima_free_measurements() to free a list of
> > > > > measurements
> > > > > and call it when an IMA namespace is deleted.
> > > > This one worries me quite a lot.  What seems to be happening in
> > > > this
> > > > code:
> > > > 
> > > > > @@ -107,7 +100,7 @@ static int ima_add_digest_entry(struct
> > > > > ima_namespace *ns,
> > > > >           qe->entry = entry;
> > > > >    
> > > > >           INIT_LIST_HEAD(&qe->later);
> > > > > -       list_add_tail_rcu(&qe->later, &ima_measurements);
> > > > > +       list_add_tail_rcu(&qe->later, &ns->ima_measurements);
> > > > >    
> > > > >           atomic_long_inc(&ns->ima_htable.len);
> > > > >           if (update_htable) {
> > > > > 
> > > > is that we now only add the measurements to the namespace list,
> > > > but
> > > > that list is freed when the namespace dies.  However, the
> > > > measurement
> > > > is still extended through the PCRs meaning we have incomplete
> > > > information for a replay after the namespace dies?
> > > *Not at all.* The measurement list of the namespace is
> > > independent
> > > of
> > > the host.
> > > 
> > > The cover letter states:
> > I get that the host can set up a policy to log everything in the
> > namespace, but that wasn't my question.  My question is can the
> > guest
> > set up a policy to log something that doesn't go into the host log
> > (because the host hasn't asked for it to be logged) but extends a
> > PCR
> > anyway, thus destroying the ability of the host to do log replay.
> 
> host log goes with host TPM and vice versa
> 
> guest log goes with (optional) vTPM and vice version

But that's what doesn't seem to happen ... ima_pcr_extend isn't
virtualized and it's always called from ima_add_template_entry()
meaning the physical TPM is always extended even for a namespace only
entry.

> Extending the PCR of the host's TPM would require the data to be
> logged in the host log as well. So, no, it's not possible.

Well, exactly: if you don't have or want a vTPM per container the only
way to attest is via the physical TPM which means all entries in the
namespace must be in the host log, so the host owner can quote and
reply and they can split the attested log and give assurance to the
namespaces that their entries are correct.

James