Linux-Fsdevel Archive on lore.kernel.org
 help / color / Atom feed
From: Janne Karhunen <janne.karhunen@gmail.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: linux-integrity@vger.kernel.org,
	linux-security-module <linux-security-module@vger.kernel.org>,
	Ken Goldman <kgold@linux.ibm.com>,
	david.safford@gmail.com, "Wiseman, Monty (GE Global Research,
	US)" <monty.wiseman@ge.com>, Amir Goldstein <amir73il@gmail.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v2] ima: export the measurement list when needed
Date: Mon, 10 Feb 2020 10:04:42 +0200
Message-ID: <CAE=NcrYhz7zrhxZoVDSvfs+Cd-vNX30gGXU9Xu4K7ft-1ozN2g@mail.gmail.com> (raw)
In-Reply-To: <1580998432.5585.411.camel@linux.ibm.com>

On Thu, Feb 6, 2020 at 4:14 PM Mimi Zohar <zohar@linux.ibm.com> wrote:

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

This is a good point. I will adapt the patch to this.


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

Are we looking at protecting this file from a root exploit and the
potential DOS it might cause? In the original patch the file was root
writable only. As far as further limitations go, the easiest would
probably be to use the file immutable bit. If the kernel opens the
file and sets the immutable bit, it is the only entity that can ever
write to it - not even another root task could directly write to it.
The kernel could, as long as it keeps the file open.


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

I didn't quickly see what the actual problem is that the vfs_tmpfile
solves in this context, will check.


--
Janne

  reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200108111743.23393-1-janne.karhunen@gmail.com>
     [not found] ` <CAE=NcrZrbRinOAbB+k1rjhcae3nqfJ8snC_EnY8njMDioM7=vg@mail.gmail.com>
2020-02-06 14:13   ` Mimi Zohar
2020-02-10  8:04     ` Janne Karhunen [this message]
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

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='CAE=NcrYhz7zrhxZoVDSvfs+Cd-vNX30gGXU9Xu4K7ft-1ozN2g@mail.gmail.com' \
    --to=janne.karhunen@gmail.com \
    --cc=amir73il@gmail.com \
    --cc=david.safford@gmail.com \
    --cc=kgold@linux.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=monty.wiseman@ge.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

Linux-Fsdevel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/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-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \
		linux-fsdevel@vger.kernel.org
	public-inbox-index linux-fsdevel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git