All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Petr Vorel <pvorel@suse.cz>, ltp@lists.linux.it
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>,
	Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
	Tushar Sugandhi <tusharsu@linux.microsoft.com>,
	linux-integrity@vger.kernel.org
Subject: Re: [PATCH v5 0/4] TPM 2.0 fixes in IMA tests
Date: Thu, 17 Dec 2020 00:20:55 -0500	[thread overview]
Message-ID: <aec8d4d757c674b3fdb4caaf3d89317d230b91e7.camel@linux.ibm.com> (raw)
In-Reply-To: <20201214221946.6340-1-pvorel@suse.cz>

Hi Petr,

On Mon, 2020-12-14 at 23:19 +0100, Petr Vorel wrote:
> The only problem which bothers me is failure on ima_policy=tcb:
> 
> evmctl ima_measurement /sys/kernel/security/integrity/ima/binary_runtime_measurements -vv
> ...
> sha256: PCRAgg  10: c19866f10132282d4cf20ca45f50078db843f95dc8d1ea8819d0e240cdf3b21c
> sha256: TPM PCR-10: df913daa0437a2365f710f6d93a4f2d37146414425d9aaa60740dc635d187158
> sha256: PCRAgg 10 does not match TPM PCR-10
> Failed to match per TPM bank or SHA1 padded TPM digest(s) (count 1446)
> errno: No such file or directory (2)
> 
> Thus test get failure for the fist run without --ignore-violations
> ...
> ima_tpm 1 TINFO: using command: evmctl ima_boot_aggregate -v
> Using tss2-rc-decode to read PCRs.
> ima_tpm 1 TINFO: IMA boot aggregate: '0756853d9378ff6473966e20610a8d1cb97e4dc613cb87adf5e870c8eb93fd0f'
> ima_tpm 1 TPASS: bios boot aggregate matches IMA boot aggregate
> ima_tpm 2 TINFO: verify PCR values
> ima_tpm 2 TINFO: real PCR-10: '6d8aec6291c0c19efdee50e20899939135be073cd4d6e9063e53386f54f9487d'
> ima_tpm 2 TFAIL: evmctl failed, trying with --ignore-violations
> ima_tpm 2 TINFO: aggregate PCR-10: '6d8aec6291c0c19efdee50e20899939135be073cd4d6e9063e53386f54f9487d'
> ima_tpm 2 TPASS: aggregate PCR value matches real PCR value
> ima_tpm 3 TINFO: AppArmor enabled, this may affect test results
> ima_tpm 3 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root)
> ima_tpm 3 TINFO: loaded AppArmor profiles: none
> 
> Summary:
> passed   2
> failed   1
> skipped  0
> warnings 0
> 
> IMHO unless this is specific for this particular TPM we should skip test
> if ima_policy=tcb.

No, I don't think so.  Violations are a result of a file being opened
for read and write at the same time.  Opening a file for write, when it
is already open for read, results in a Time of Measure/Time of Use
(ToMToU) violation.  Opening a file for read, when it is already open
for write, results in an open_writer violation.  One of the more common
reasons for these violations are log files.

With the builtin TCB measurement policy enabled on the boot command
line, files are measured from the beginning, before a custom policy is
loaded.  Normally a custom policy is loaded after an LSM policy has
been loaded, allowing IMA policy rules to be defined in terms of LSM
labels.

Verifying the IMA measurement list against the TPM PCRs is an important
test.  Ignoring violations doesn't make sense either.   Perhaps if a
custom policy has not been loaded, emit an informational message and
skip the test without "--ignore-violations".

thanks,

Mimi


WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.ibm.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v5 0/4] TPM 2.0 fixes in IMA tests
Date: Thu, 17 Dec 2020 00:20:55 -0500	[thread overview]
Message-ID: <aec8d4d757c674b3fdb4caaf3d89317d230b91e7.camel@linux.ibm.com> (raw)
In-Reply-To: <20201214221946.6340-1-pvorel@suse.cz>

Hi Petr,

On Mon, 2020-12-14 at 23:19 +0100, Petr Vorel wrote:
> The only problem which bothers me is failure on ima_policy=tcb:
> 
> evmctl ima_measurement /sys/kernel/security/integrity/ima/binary_runtime_measurements -vv
> ...
> sha256: PCRAgg  10: c19866f10132282d4cf20ca45f50078db843f95dc8d1ea8819d0e240cdf3b21c
> sha256: TPM PCR-10: df913daa0437a2365f710f6d93a4f2d37146414425d9aaa60740dc635d187158
> sha256: PCRAgg 10 does not match TPM PCR-10
> Failed to match per TPM bank or SHA1 padded TPM digest(s) (count 1446)
> errno: No such file or directory (2)
> 
> Thus test get failure for the fist run without --ignore-violations
> ...
> ima_tpm 1 TINFO: using command: evmctl ima_boot_aggregate -v
> Using tss2-rc-decode to read PCRs.
> ima_tpm 1 TINFO: IMA boot aggregate: '0756853d9378ff6473966e20610a8d1cb97e4dc613cb87adf5e870c8eb93fd0f'
> ima_tpm 1 TPASS: bios boot aggregate matches IMA boot aggregate
> ima_tpm 2 TINFO: verify PCR values
> ima_tpm 2 TINFO: real PCR-10: '6d8aec6291c0c19efdee50e20899939135be073cd4d6e9063e53386f54f9487d'
> ima_tpm 2 TFAIL: evmctl failed, trying with --ignore-violations
> ima_tpm 2 TINFO: aggregate PCR-10: '6d8aec6291c0c19efdee50e20899939135be073cd4d6e9063e53386f54f9487d'
> ima_tpm 2 TPASS: aggregate PCR value matches real PCR value
> ima_tpm 3 TINFO: AppArmor enabled, this may affect test results
> ima_tpm 3 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root)
> ima_tpm 3 TINFO: loaded AppArmor profiles: none
> 
> Summary:
> passed   2
> failed   1
> skipped  0
> warnings 0
> 
> IMHO unless this is specific for this particular TPM we should skip test
> if ima_policy=tcb.

No, I don't think so.  Violations are a result of a file being opened
for read and write at the same time.  Opening a file for write, when it
is already open for read, results in a Time of Measure/Time of Use
(ToMToU) violation.  Opening a file for read, when it is already open
for write, results in an open_writer violation.  One of the more common
reasons for these violations are log files.

With the builtin TCB measurement policy enabled on the boot command
line, files are measured from the beginning, before a custom policy is
loaded.  Normally a custom policy is loaded after an LSM policy has
been loaded, allowing IMA policy rules to be defined in terms of LSM
labels.

Verifying the IMA measurement list against the TPM PCRs is an important
test.  Ignoring violations doesn't make sense either.   Perhaps if a
custom policy has not been loaded, emit an informational message and
skip the test without "--ignore-violations".

thanks,

Mimi


  parent reply	other threads:[~2020-12-17  5:24 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-14 22:19 [PATCH v5 0/4] TPM 2.0 fixes in IMA tests Petr Vorel
2020-12-14 22:19 ` [LTP] " Petr Vorel
2020-12-14 22:19 ` [PATCH v5 1/4] IMA: Move get_algorithm_digest(), set_digest_index() to ima_setup.sh Petr Vorel
2020-12-14 22:19   ` [LTP] " Petr Vorel
2020-12-17 16:56   ` Mimi Zohar
2020-12-17 16:56     ` [LTP] " Mimi Zohar
2020-12-18 11:27     ` Petr Vorel
2020-12-18 11:27       ` [LTP] " Petr Vorel
2020-12-18 12:10       ` Mimi Zohar
2020-12-18 12:10         ` [LTP] " Mimi Zohar
2020-12-14 22:19 ` [PATCH v5 2/4] IMA: Rewrite ima_boot_aggregate.c to new API Petr Vorel
2020-12-14 22:19   ` [LTP] " Petr Vorel
2020-12-14 22:19 ` [PATCH v5 3/4] ima_tpm.sh: Fix calculating boot aggregate Petr Vorel
2020-12-14 22:19   ` [LTP] " Petr Vorel
2020-12-17 18:12   ` Mimi Zohar
2020-12-17 18:12     ` [LTP] " Mimi Zohar
2020-12-17 19:36     ` Petr Vorel
2020-12-17 19:36       ` [LTP] " Petr Vorel
2020-12-14 22:19 ` [PATCH v5 4/4] ima_tpm.sh: Fix calculating PCR aggregate Petr Vorel
2020-12-14 22:19   ` [LTP] " Petr Vorel
2020-12-17 19:16   ` Mimi Zohar
2020-12-17 19:16     ` [LTP] " Mimi Zohar
2020-12-17  5:20 ` Mimi Zohar [this message]
2020-12-17  5:20   ` [LTP] [PATCH v5 0/4] TPM 2.0 fixes in IMA tests Mimi Zohar
2020-12-17  8:33   ` Petr Vorel
2020-12-17  8:33     ` [LTP] " Petr Vorel
2020-12-17 19:23     ` Mimi Zohar
2020-12-17 19:23       ` [LTP] " Mimi Zohar
2020-12-18 11:45       ` Petr Vorel
2020-12-18 11:45         ` [LTP] " Petr Vorel

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=aec8d4d757c674b3fdb4caaf3d89317d230b91e7.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=ltp@lists.linux.it \
    --cc=nramas@linux.microsoft.com \
    --cc=pvorel@suse.cz \
    --cc=tusharsu@linux.microsoft.com \
    --cc=zohar@linux.vnet.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.