mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ken Goldman <kgold@linux.vnet.ibm.com>
To: linux-ima-devel@lists.sourceforge.net
Cc: linux-fsdevel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [Linux-ima-devel] [PATCH 11/12] ima: don't report measurements if digests are included in the loaded lists
Date: Wed, 9 Aug 2017 16:36:01 -0400	[thread overview]
Message-ID: <96860a64-2ba1-d445-dd8e-08b131fe402b@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170725154423.24845-12-roberto.sassu@huawei.com>

On 7/25/2017 11:44 AM, Roberto Sassu wrote:
> Don't report measurements if the file digest has been included in
> an uploaded digest list.
> 
> The advantage of this solution is that the boot time overhead, when
> a TPM is available, is very small because a PCR is extended only
> for unknown files. The disadvantage is that verifiers do not know
> anymore which and when files are accessed (they must assume that
> the worst case happened, i.e. all files have been accessed).

Am I reading this correctly that you want to measure certain files, but 
not ones that have been included in a "digest list", which sounds like a 
white list of sorts.

If so, I have two concerns:

1 - How would the client get this digest list?  Shouldn't it be up to 
the relying party to decide what is trusted and not trusted, not the client?

What of the case with two different relying parties that have a 
different list of trusted applications?  E.g., one trusts any version of 
program X, while the other trusts only version 3.1 and up?

2 - What about files on the digest list that were not run?  The relying 
party may want to know if a program wasn't run?  E.g., antivirus or a 
firewall.

If the rule is "don't measure if it's on the digest list", how does the 
relying party know if it was run?

  reply	other threads:[~2017-08-09 20:35 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-25 15:44 [PATCH 00/12] ima: measure digest lists instead of individual files Roberto Sassu
2017-07-25 15:44 ` [PATCH 01/12] ima: generalize ima_read_policy() Roberto Sassu
2017-07-25 15:44 ` [PATCH 02/12] ima: generalize ima_write_policy() Roberto Sassu
2017-07-25 15:44 ` [PATCH 03/12] ima: generalize policy file operations Roberto Sassu
2017-07-25 15:44 ` [PATCH 04/12] ima: use ima_show_htable_value to show hash table data Roberto Sassu
2017-07-25 15:44 ` [PATCH 05/12] ima: add functions to manage digest lists Roberto Sassu
2017-07-25 15:44 ` [PATCH 06/12] ima: added parser of digest lists metadata Roberto Sassu
2017-07-27  5:15   ` kbuild test robot
2017-08-01 10:17   ` [PATCH, RESEND " Roberto Sassu
2017-07-25 15:44 ` [PATCH 07/12] ima: added parser for compact digest list Roberto Sassu
2017-07-25 15:44 ` [PATCH 08/12] ima: added parser for RPM data type Roberto Sassu
2017-07-27  5:03   ` kbuild test robot
2017-08-01 10:20   ` [PATCH, RESEND " Roberto Sassu
2017-08-01 10:27     ` Christoph Hellwig
2017-08-01 10:58       ` Roberto Sassu
2017-08-02  7:22         ` [Linux-ima-devel] " James Morris
2017-08-02 11:22           ` Roberto Sassu
2017-08-09  9:15           ` Roberto Sassu
2017-08-09 14:30             ` Mimi Zohar
2017-08-09 17:18               ` Roberto Sassu
2017-08-10 13:12                 ` Mimi Zohar
2017-08-17  9:15                   ` Roberto Sassu
2017-07-25 15:44 ` [PATCH 09/12] ima: introduce securityfs interfaces for digest lists Roberto Sassu
2017-07-27  5:38   ` kbuild test robot
2017-07-25 15:44 ` [PATCH 10/12] ima: disable digest lookup if digest lists are not measured Roberto Sassu
2017-07-25 15:44 ` [PATCH 11/12] ima: don't report measurements if digests are included in the loaded lists Roberto Sassu
2017-08-09 20:36   ` Ken Goldman [this message]
2017-08-17  8:32     ` [Linux-ima-devel] " Roberto Sassu
2017-07-25 15:44 ` [PATCH 12/12] ima: added Documentation/security/IMA-digest-lists.txt Roberto Sassu
2017-07-26 21:54 ` [PATCH 00/12] ima: measure digest lists instead of individual files 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=96860a64-2ba1-d445-dd8e-08b131fe402b@linux.vnet.ibm.com \
    --to=kgold@linux.vnet.ibm.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-ima-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome