All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: linux-integrity@vger.kernel.org, containers@lists.linux.dev,
	Mimi Zohar <zohar@linux.ibm.com>,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	Stefan Berger <stefanb@linux.ibm.com>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	 krzysztof.struczynski@huawei.com,
	Roberto Sassu <roberto.sassu@huawei.com>,
	 Michael Peters <mpeters@redhat.com>,
	Luke Hinds <lhinds@redhat.com>,
	Lily Sturmann <lsturman@redhat.com>,
	 Patrick Uiterwijk <puiterwi@redhat.com>,
	Christian Brauner <christian@brauner.io>
Subject: Re: [RFC 3/3] ima: make the integrity inode cache per namespace
Date: Mon, 29 Nov 2021 07:50:52 -0500	[thread overview]
Message-ID: <755446b10c8415fd469b814535c4a12964af3264.camel@HansenPartnership.com> (raw)
In-Reply-To: <20211129045834.GB20606@mail.hallyn.com>

On Sun, 2021-11-28 at 22:58 -0600, Serge E. Hallyn wrote:
> On Sat, Nov 27, 2021 at 04:45:49PM +0000, James Bottomley wrote:
> > Currently we get one entry in the IMA log per unique file
> > event.  So, if you have a measurement policy and it measures a
> > particular binary it will not get measured again if it is
> > subsequently executed. For Namespaced IMA, the correct behaviour
> > seems to be to log once per inode per namespace (so every unique
> > execution in a namespace gets a separate log entry).  Since logging
> > once per inode per namespace is
> 
> I suspect I'll need to do a more in depth reading of the existing
> code, but I'll ask the lazy question anyway (since you say "the
> correct behavior seems to be") - is it actually important that
> files which were appraised under a parent namespace's policy already
> should be logged again?

I think so.  For a couple of reasons, assuming the namespace eventually
gets its own log entries, which the next incremental patch proposed to
do by virtualizing the securityfs entries.  If you don't do this:

   1. The namespace log will be incomplete in a random way depending on
      what execution preceded it.  This violates the principle of least
      surprise, because you at least expect the IMA log to be consistent
      per set of executions.
   2. A malicious namespace owner can use the missing information in their
      log to infer the execution of others, which is an information leak
      IMA tries to prevent by keeping the log readable only by root.

>   Since you used the word "log" I'm assuming this isn't building a
> running hash like a tpm pcr where skipping one would invalidate
> rmeote attestation?

Their is only one IMA log, so each entry must be extended through the
PCR to keep the quote correct.  That means each per namespace entry
does extend the PCR.  However, since the entire entry is logged and the
namespace uuid is part of the entry, the entry hash is different for
each, so the IMA rule about duplicate log entries doesn't apply, if
that was the worry?

James



  reply	other threads:[~2021-11-29 12:50 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-27 16:45 [RFC 0/3] Namespace IMA James Bottomley
2021-11-27 16:45 ` [RFC 1/3] userns: add uuid field James Bottomley
2021-11-28  4:45   ` Serge E. Hallyn
2021-11-28 13:29     ` James Bottomley
2021-11-28 15:18       ` Serge E. Hallyn
2021-11-28 18:00         ` James Bottomley
2021-11-28 20:47           ` Serge E. Hallyn
2021-11-28 21:21             ` James Bottomley
2021-11-28 21:49               ` Serge E. Hallyn
2021-11-28 22:56                 ` James Bottomley
2021-11-29  1:59                   ` Serge E. Hallyn
2021-11-29 13:49                     ` Stefan Berger
2021-11-29 13:56                       ` Christian Brauner
2021-11-29 14:19                         ` Stefan Berger
2021-11-30 13:09                         ` James Bottomley
2021-11-29 13:12                 ` Christian Brauner
2021-11-29 13:46                   ` James Bottomley
2021-11-27 16:45 ` [RFC 2/3] ima: Namespace IMA James Bottomley
2021-11-29  2:52   ` Serge E. Hallyn
2021-11-27 16:45 ` [RFC 3/3] ima: make the integrity inode cache per namespace James Bottomley
2021-11-29  4:58   ` Serge E. Hallyn
2021-11-29 12:50     ` James Bottomley [this message]
2021-11-29 13:53       ` Stefan Berger
2021-11-29 14:10         ` James Bottomley
2021-11-29 14:22           ` Christian Brauner
2021-11-29 14:46             ` James Bottomley
2021-11-29 15:27               ` Stefan Berger
2021-11-29 16:23                 ` James Bottomley
2021-11-29 15:35               ` Serge E. Hallyn
2021-11-29 16:07                 ` Stefan Berger
2021-11-30  4:42                   ` Serge E. Hallyn
2021-11-29 16:16                 ` Christian Brauner
2021-11-29 16:23                   ` Christian Brauner
2021-11-29 17:04                   ` Stefan Berger
2021-11-29 17:29                     ` James Bottomley
2021-11-30  5:03                     ` Serge E. Hallyn
2021-11-30 11:55                       ` Stefan Berger
2021-11-30 13:33                         ` Christian Brauner
2021-11-30 13:44                       ` Christian Brauner
2021-11-30 13:38                     ` Christian Brauner
2021-11-29 16:44                 ` James Bottomley
2021-11-30  4:59                   ` Serge E. Hallyn
2021-11-30 13:00                     ` James Bottomley
2021-11-29 14:30           ` Stefan Berger
2021-11-29 15:08             ` James Bottomley
2021-11-29 16:20             ` Christian Brauner

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=755446b10c8415fd469b814535c4a12964af3264.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=christian@brauner.io \
    --cc=containers@lists.linux.dev \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=krzysztof.struczynski@huawei.com \
    --cc=lhinds@redhat.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=lsturman@redhat.com \
    --cc=mpeters@redhat.com \
    --cc=puiterwi@redhat.com \
    --cc=roberto.sassu@huawei.com \
    --cc=serge@hallyn.com \
    --cc=stefanb@linux.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.