diff for duplicates of <1516919365.6513.72.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 31912b8..ff30ed3 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -13,8 +13,8 @@ On Thu, 2018-01-25 at 21:30 +0100, Petr Vorel wrote: > > > > Comments are welcomed. > -> > The LTP tests are quite dated, and need some major rework. I really -> > appreciate your addressing some of the issues. Below are some +> > The LTP tests are quite dated, and need some major rework. I really +> > appreciate your addressing some of the issues. Below are some > > additional ones. > Thanks a lot for your comments. As you didn't report any regression in my patch-set, I'm > for merging it as it's an improvement. But I see there is more work to be done. @@ -31,26 +31,26 @@ Ok, I'll take a look. > > Tests "ima02 ima_measurement.sh" and "ima04 ima_violations.sh" assume -> > files are created on a filesystem in policy. The "measure.policy" -> > excludes tmpfs, yet TMPDIR defaults to a tmpfs filesystem. There are +> > files are created on a filesystem in policy. The "measure.policy" +> > excludes tmpfs, yet TMPDIR defaults to a tmpfs filesystem. There are > > a couple of ways of resolving this problem (eg. removing tmpfs from > > the "measure.policy", use a RAM block device instead of tmpfs, etc). -> > Since the builtin "ima_policy=tcb" also excludes tmpfs, not using a +> > Since the builtin "ima_policy=tcb" also excludes tmpfs, not using a > > tmpfs filesystem would be preferable. > OK, I'll try to implement test using RAM block device. It would be nice to be able to define policies that limit testing to a -specific filesystem/device. Without being able to limit IMA-appraisal +specific filesystem/device. Without being able to limit IMA-appraisal testing to specific devices, things might stop working rather quickly. > > > Originally IMA allowed a builtin policy to be replaced with a custom > > policy, by simply cat'ing a file into the securityfs IMA policy file. > > Currently, if new rules can be added to the custom policy (Kconfig -> > IMA_WRITE_POLICY enabled), the policy file must be signed. Similarly, +> > IMA_WRITE_POLICY enabled), the policy file must be signed. Similarly, > > if the builtin "secure-boot" policy is defined on the boot command -> > line, the custom policy must be signed. Test "ima01 ima_policy.sh" +> > line, the custom policy must be signed. Test "ima01 ima_policy.sh" > > should first detect if the policy must be signed, before running the > > tests. @@ -59,10 +59,10 @@ testing to specific devices, things might stop working rather quickly. > embedded devices (guessing from [2], [3]), which might not have either of them. Until the IMA-measurement list supports TPM 2.0 hash agility, the -template name defines the old ("ima") vs. new formats. The builtin +template name defines the old ("ima") vs. new formats. The builtin new template formats are "ima-ng" and "ima-sig", but custom formats can be defined (eg. ima_template_fmt="d-ng|n-ng|sig") on the boot -command line. "d-ng|n-ng|sig" is the definition for ima-sig. +command line. "d-ng|n-ng|sig" is the definition for ima-sig. > > ima_boot_aggregate.c defines the BIOS MAX_EVENT_SIZE BIOS size as 500, > > but I'm currently seeing BIOS events larger than 4k. @@ -71,7 +71,7 @@ command line. "d-ng|n-ng|sig" is the definition for ima-sig. > Any reference to it? According to Kenneth Goldman, the maximum BIOS event entry for TPM 1.2 -is undefined. For TPM 2.0 this was corrected. The spec says, "For +is undefined. For TPM 2.0 this was corrected. The spec says, "For software parsing the event log, the parser can choose an arbitrary maximum size, but this specification recommends a maximum value for the TCG_PCR_EVENT2.eventSize field of 1MB." @@ -81,9 +81,9 @@ TPM 1.2. > > Since these tests were first written, Roberto's IMA templates and -> > Dmitry's support for larger digests were upstreamed. With the new +> > Dmitry's support for larger digests were upstreamed. With the new > > template format, the file hash is prefixed with the hash algorithm. -> > Before comparing the calculated boot aggregate with the value in the +> > Before comparing the calculated boot aggregate with the value in the > > IMA measurement list, the hash algorithm needs to be removed. > Do you mean entries in /sys/kernel/security/ima/ascii_runtime_measurements ? @@ -92,8 +92,8 @@ TPM 1.2. > system with config CONFIG_IMA_DEFAULT_HASH_SHA1=y > 10 2990cfe74ff309268e4fb928102574c28f9bb876 ima-ng sha1:71b543ad6af36b0976d0e3f71fed4ce0954eda0c /var/log/messages -Exactly. The following code snippet strips off the hash algorithm, -before doing the hash comparison. I'm sure there are better ways of +Exactly. The following code snippet strips off the hash algorithm, +before doing the hash comparison. I'm sure there are better ways of doing it. +++ b/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh @@ -117,26 +117,26 @@ doing it. The list of supported hash algorithms is defined in include/uapi/linux/hash_info.h. -The first entry, the boot aggregate, is always sha1. The rest of the +The first entry, the boot aggregate, is always sha1. The rest of the measurements will be the same hash algorithm, either as Kconfig defined or as specified on the boot command line "ima_hash=" option, -per boot. +per boot. With the support for carrying the IMA-measurement list across kexec, the measurement list might contain entries with different hash algorithms. -> > +> > > > For the new template format measurement lists, walking the measurement > > list, re-calculating the PCRs and comparing them with the HW or vTPM -> > PCRs fail. The ima-evm-utils package has a working version. Invoke +> > PCRs fail. The ima-evm-utils package has a working version. Invoke > > "evmctl" with the "ima_measurement" option. > So you mean that src/ima_measure.c is broken and should be replaced by evmctl from your > repository on sf.net [4]? Fortunately this package is on all major distros [5] (except > Debian, but Ubuntu package is installable on Debian), so we don't need to include your > repository as submodule. -Fantastic! So we'll concentrate on extending ima-evm-utils. +Fantastic! So we'll concentrate on extending ima-evm-utils. thanks, diff --git a/a/content_digest b/N1/content_digest index e2d3fb2..d3d73ab 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,13 +2,9 @@ "ref\01516815417.3686.55.camel@linux.vnet.ibm.com\0" "ref\020180125203057.mzzpilp6i43xftka@dell5510\0" "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" - "Subject\0Re: [RFC PATCH 0/2] IMA: Rewrite tests into new API + fixes\0" + "Subject\0[LTP] [RFC PATCH 0/2] IMA: Rewrite tests into new API + fixes\0" "Date\0Thu, 25 Jan 2018 17:29:25 -0500\0" - "To\0Petr Vorel <pvorel@suse.cz>\0" - "Cc\0ltp@lists.linux.it" - Dmitry Kasatkin <dmitry.kasatkin@huawei.com> - linux-integrity@vger.kernel.org - " Roberto Sassu <roberto.sassu@polito.it>\0" + "To\0ltp@lists.linux.it\0" "\00:1\0" "b\0" "On Thu, 2018-01-25 at 21:30 +0100, Petr Vorel wrote:\n" @@ -26,8 +22,8 @@ "> \n" "> > > Comments are welcomed.\n" "> \n" - "> > The LTP tests are quite dated, and need some major rework. I really\n" - "> > appreciate your addressing some of the issues. Below are some\n" + "> > The LTP tests are quite dated, and need some major rework. \302\240I really\n" + "> > appreciate your addressing some of the issues. \302\240Below are some\n" "> > additional ones.\n" "> Thanks a lot for your comments. As you didn't report any regression in my patch-set, I'm\n" "> for merging it as it's an improvement. But I see there is more work to be done.\n" @@ -44,26 +40,26 @@ "\n" "\n" "> > Tests \"ima02 ima_measurement.sh\" and \"ima04 ima_violations.sh\" assume\n" - "> > files are created on a filesystem in policy. The \"measure.policy\"\n" - "> > excludes tmpfs, yet TMPDIR defaults to a tmpfs filesystem. There are\n" + "> > files are created on a filesystem in policy. \302\240The \"measure.policy\"\n" + "> > excludes tmpfs, yet TMPDIR defaults to a tmpfs filesystem. \302\240There are\n" "> > a couple of ways of resolving this problem (eg. removing tmpfs from\n" "> > the \"measure.policy\", use a RAM block device instead of tmpfs, etc).\n" - "> > Since the builtin \"ima_policy=tcb\" also excludes tmpfs, not using a\n" + "> > \302\240Since the builtin \"ima_policy=tcb\" also excludes tmpfs, not using a\n" "> > tmpfs filesystem would be preferable.\n" "\n" "> OK, I'll try to implement test using RAM block device.\n" "\n" "It would be nice to be able to define policies that limit testing to a\n" - "specific filesystem/device. Without being able to limit IMA-appraisal \n" + "specific filesystem/device. \302\240Without being able to limit IMA-appraisal \n" "testing to specific devices, things might stop working rather quickly.\n" "\n" "> \n" "> > Originally IMA allowed a builtin policy to be replaced with a custom\n" "> > policy, by simply cat'ing a file into the securityfs IMA policy file.\n" "> > Currently, if new rules can be added to the custom policy (Kconfig\n" - "> > IMA_WRITE_POLICY enabled), the policy file must be signed. Similarly,\n" + "> > IMA_WRITE_POLICY enabled), the policy file must be signed. \302\240Similarly,\n" "> > if the builtin \"secure-boot\" policy is defined on the boot command\n" - "> > line, the custom policy must be signed. Test \"ima01 ima_policy.sh\"\n" + "> > line, the custom policy must be signed. \302\240Test \"ima01 ima_policy.sh\"\n" "> > should first detect if the policy must be signed, before running the\n" "> > tests.\n" "\n" @@ -72,10 +68,10 @@ "> embedded devices (guessing from [2], [3]), which might not have either of them.\n" "\n" "Until the IMA-measurement list supports TPM 2.0 hash agility, the\n" - "template name defines the old (\"ima\") vs. new formats. The builtin\n" + "template name defines the old (\"ima\") vs. new formats. \302\240The builtin\n" "new template formats are \"ima-ng\" and \"ima-sig\", but custom formats\n" "can be defined (eg. ima_template_fmt=\"d-ng|n-ng|sig\") on the boot\n" - "command line. \"d-ng|n-ng|sig\" is the definition for ima-sig.\n" + "command line. \302\240\"d-ng|n-ng|sig\" is the definition for ima-sig.\n" "\n" "> > ima_boot_aggregate.c defines the BIOS MAX_EVENT_SIZE BIOS size as 500,\n" "> > but I'm currently seeing BIOS events larger than 4k.\n" @@ -84,7 +80,7 @@ "> Any reference to it?\n" "\n" "According to Kenneth Goldman, the maximum BIOS event entry for TPM 1.2\n" - "is undefined. For TPM 2.0 this was corrected. The spec says, \"For\n" + "is undefined. \302\240For TPM 2.0 this was corrected. \302\240The spec says, \"For\n" "software parsing the event log, the parser can choose an arbitrary\n" "maximum size, but this specification recommends a maximum value for\n" "the TCG_PCR_EVENT2.eventSize field of 1MB.\"\n" @@ -94,9 +90,9 @@ "\n" "\n" "> > Since these tests were first written, Roberto's IMA templates and\n" - "> > Dmitry's support for larger digests were upstreamed. With the new\n" + "> > Dmitry's support for larger digests were upstreamed. \302\240With the new\n" "> > template format, the file hash is prefixed with the hash algorithm.\n" - "> > Before comparing the calculated boot aggregate with the value in the\n" + "> > \302\240Before comparing the calculated boot aggregate with the value in the\n" "> > IMA measurement list, the hash algorithm needs to be removed.\n" "\n" "> Do you mean entries in /sys/kernel/security/ima/ascii_runtime_measurements ?\n" @@ -105,8 +101,8 @@ "> system with config CONFIG_IMA_DEFAULT_HASH_SHA1=y\n" "> 10 2990cfe74ff309268e4fb928102574c28f9bb876 ima-ng sha1:71b543ad6af36b0976d0e3f71fed4ce0954eda0c /var/log/messages\n" "\n" - "Exactly. The following code snippet strips off the hash algorithm,\n" - "before doing the hash comparison. I'm sure there are better ways of\n" + "Exactly. \302\240The following code snippet strips off the hash algorithm,\n" + "before doing the hash comparison. \302\240I'm sure there are better ways of\n" "doing it.\n" "\n" "+++ b/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh\n" @@ -130,29 +126,29 @@ "The list of supported hash algorithms is defined in\n" "include/uapi/linux/hash_info.h.\n" "\n" - "The first entry, the boot aggregate, is always sha1. The rest of the\n" + "The first entry, the boot aggregate, is always sha1. \302\240The rest of the\n" "measurements will be the same hash algorithm, either as Kconfig\n" "defined or as specified on the boot command line \"ima_hash=\" option,\n" - "per boot. \n" + "per boot.\302\240\n" "\n" "With the support for carrying the IMA-measurement list across kexec,\n" "the measurement list might contain entries with different hash\n" "algorithms.\n" "\n" - "> > \n" + "> > \302\240\n" "> > For the new template format measurement lists, walking the measurement\n" "> > list, re-calculating the PCRs and comparing them with the HW or vTPM\n" - "> > PCRs fail. The ima-evm-utils package has a working version. Invoke\n" + "> > PCRs fail. \302\240The ima-evm-utils package has a working version. \302\240Invoke\n" "> > \"evmctl\" with the \"ima_measurement\" option.\n" "> So you mean that src/ima_measure.c is broken and should be replaced by evmctl from your\n" "> repository on sf.net [4]? Fortunately this package is on all major distros [5] (except\n" "> Debian, but Ubuntu package is installable on Debian), so we don't need to include your\n" "> repository as submodule.\n" "\n" - "Fantastic! So we'll concentrate on extending ima-evm-utils.\n" + "Fantastic! \302\240So we'll concentrate on extending ima-evm-utils.\n" "\n" "thanks,\n" "\n" Mimi -67fa9bb0b3651a06753984a958223f36b111d7d5a8899564c46a8df6388a1cb5 +fcc052dd53631432912572188822066274e8e02bd4e57f82b051d0e923507b3a
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.