From: roberto.sassu@huawei.com (Roberto Sassu)
To: linux-security-module@vger.kernel.org
Subject: [Linux-ima-devel] [PATCH 11/12] ima: don't report measurements if digests are included in the loaded lists
Date: Thu, 17 Aug 2017 10:32:40 +0200 [thread overview]
Message-ID: <f0dd1d3f-766a-0a8a-ccfc-e6b1ddd06adf@huawei.com> (raw)
In-Reply-To: <96860a64-2ba1-d445-dd8e-08b131fe402b@linux.vnet.ibm.com>
On 8/9/2017 10:36 PM, Ken Goldman wrote:
> 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?
The client can get the digest list from the RPM database or the
measurement list of a previous boot. A verifier still decides if the
client is trusted or not, depending on what could be possibly accessed
rather than what has been accessed.
> 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?
There are two ways to provide more accurate information (make the list
of possibly accessed files closer to the list of accessed files):
1) use the measurement list of a previous boot as a source for
the digest list
2) use the RPM database as a source for the digest lists, and load the
headers of the latest version of RPMs
and:
load only the headers of RPMs including files that appear in the
measurement list of a previous boot (this solution should be
preferred to solution 1, as signature-based attestation can be done)
> 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?
If a measurement list does not contain unknown digests, this means that
no malicious software was loaded. But, if the measurement list contains
the digest of an antivirus binary, this does not necessarily mean that
it was loaded.
Since PCR 10 can be extended from userspace, a malicious user can
extend the PCR with the digest of a fake measurement entry reporting
the loading of the antivirus. He can then add the fake entry to the
measurement list before it is sent to verifiers, so that they won't
notice the addition.
A possible countermeasure to this attack would be to modify the TPM
driver to refuse to extend the PCRs used by IMA.
Then, IMA could be further extended to accept a list of digests of files
that will be certainly used and to create a measurement entry only after
all files have been accessed.
Roberto
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-security-module" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Qiuen PENG, Shengli WANG
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-08-17 8:32 UTC|newest]
Thread overview: 32+ 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 ` [Linux-ima-devel] " Ken Goldman
2017-08-17 8:32 ` Roberto Sassu [this message]
2017-07-25 15:44 ` [PATCH 12/12] ima: added Documentation/security/IMA-digest-lists.txt Roberto Sassu
2017-12-05 22:28 ` [Linux-ima-devel] " Ken Goldman
2017-12-06 9:22 ` 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=f0dd1d3f-766a-0a8a-ccfc-e6b1ddd06adf@huawei.com \
--to=roberto.sassu@huawei.com \
--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;
as well as URLs for NNTP newsgroup(s).