Linux-Integrity Archive on
 help / color / Atom feed
From: Mimi Zohar <>
To: Janne Karhunen <>,,
	linux-security-module <>
Cc: Ken Goldman <>,,,
	Amir Goldstein <>,
	linux-fsdevel <>
Subject: Re: [PATCH v2] ima: export the measurement list when needed
Date: Thu, 06 Feb 2020 09:13:52 -0500
Message-ID: <> (raw)
In-Reply-To: <>

Hi Janne,

On Fri, 2020-01-10 at 10:48 +0200, Janne Karhunen wrote:
> On Wed, Jan 8, 2020 at 1:18 PM Janne Karhunen <> wrote:
> >
> > Some systems can end up carrying lots of entries in the ima
> > measurement list. Since every entry is using a bit of kernel
> > memory, allow the sysadmin to export the measurement list to
> > the filesystem to free up some memory.
> Hopefully this addressed comments from everyone. The flush event can
> now be triggered by the admin anytime and unique file names can be
> used for each flush (log.1, log.2, ...) etc, so getting to the correct
> item should be easy.
> While it can now be argued that since this is an admin-driven event,
> kernel does not need to write the file. However, the intention is to
> bring out a second patch a bit later that adds a variable to define
> the max number of entries to be kept in the kernel memory and
> workqueue based automatic flushing. In those cases the kernel has to
> be able to write the file without any help from the admin..

The implications of exporting and removing records from the IMA-
measurement list needs to be considered carefully.  Verifying a TPM
quote will become dependent on knowing where the measurements are
stored.  The existing measurement list is stored in kernel memory and,
barring a kernel memory attack, is protected from modification.
 Before upstreaming this or a similar patch, there needs to be a
discussion as to how the measurement list will be protected once is it
exported to userspace.

This patch now attempts to address two very different scenarios.  The
first scenario is where userspace is requesting exporting and removing
of the measurement list records.  The other scenario is the kernel
exporting and removing of the measurement list records.  Conflating
these two different use cases might not be the right solution, as we
originally thought.

The kernel already exports the IMA measurement list to userspace via a
securityfs file.  From a userspace perspective, missing is the ability
of removing N number of records.  In this scenario, userspace would be
responsible for safely storing the measurements (e.g. blockchain).
 The kernel would only be responsible for limiting permission, perhaps
based on a capability, before removing records from the measurement

In the kernel usecase, somehow the kernel would need to safely export
the measurement list, or some portion of the measurement list, to a
file and then delete that portion.  What protects the exported records
stored in a file from modification?

Instead of exporting the measurement records, one option as suggested
by Amir Goldstein, would be to use a vfs_tmpfile() to get an anonymous
file for backing store.  The existing securityfs measurement lists
would then read from this private copy of the anonymous file.

I've Cc'ed fsdevel for additional comments/suggestions.



  parent reply index

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-08 11:17 Janne Karhunen
2020-01-10  8:48 ` Janne Karhunen
2020-01-22 15:56   ` Mimi Zohar
2020-01-23  8:41     ` Janne Karhunen
2020-01-26 17:01       ` Mimi Zohar
2020-01-27  9:03         ` Janne Karhunen
2020-02-06 14:13   ` Mimi Zohar [this message]
2020-02-10  8:04     ` Janne Karhunen
2020-02-10 15:26       ` Mimi Zohar
2020-02-10 18:18     ` david.safford
2020-02-10 20:24       ` Mimi Zohar
2020-02-11  8:06         ` Janne Karhunen
2020-02-11 16:10         ` david.safford
2020-02-11 23:10           ` Mimi Zohar
2020-02-12 21:08             ` david.safford
2020-02-13  1:03               ` Mimi Zohar
2020-02-13  6:41                 ` Janne Karhunen
2020-02-18 15:36                   ` Mimi Zohar
2020-02-13 20:11           ` Ken Goldman
2020-02-18 14:50             ` david.safford
2020-01-24 14:46 ` david.safford
2020-01-27  8:48   ` Janne Karhunen

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Integrity Archive on

Archives are clonable:
	git clone --mirror linux-integrity/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-integrity linux-integrity/ \
	public-inbox-index linux-integrity

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone