diff for duplicates of <1521038471.4508.25.camel@HansenPartnership.com> diff --git a/a/1.txt b/N1/1.txt index 0f30ed8..b59d59b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,7 +2,7 @@ On Tue, 2018-03-13 at 12:57 +0000, Safford, David (GE Global Research, US) wrote: > > > > -----Original Message----- -> > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com +> > From: James Bottomley [mailto:James.Bottomley at HansenPartnership.com > > ] > > Sent: Monday, March 12, 2018 8:07 PM > > To: Mimi Zohar <zohar@linux.vnet.ibm.com>; Jiandi An @@ -16,7 +16,7 @@ US) wrote: > > > everything accessed in the TCB. > > > > The initrd *is* part of the Trusted Computing Base because it's -> > part of the boot custody chain. That's really my point. If I +> > part of the boot custody chain. ?That's really my point. ?If I > > don't know what's in my initrd, I've broken the chain there and IMA > > can't fix it. > > @@ -27,15 +27,15 @@ US) wrote: > question. The point of deploying security measures is to make sure my system -isn't compromised. I realise the institutional view is "we didn't +isn't compromised. ?I realise the institutional view is "we didn't build the initrd" and my individual view is well, I built my own kernel -as well, so what's the difference? But the initrd in both models is +as well, so what's the difference? ?But the initrd in both models is still part of the chain. > It's not signed as a whole by someone trusted. How can the > attestation server say a given hash of the initrd as a whole is good? -I trust myself. I can get the hash at build time. In the same way as +I trust myself. ?I can get the hash at build time. ?In the same way as I sign my own kernel at build time for secure boot. > If IMA is running from the very start, it can at least measure (and @@ -50,15 +50,20 @@ I sign my own kernel at build time for secure boot. > Perhaps there is a use case where there is a known set of initrd > images, and so the bootloader's measurement of the initrd is > sufficient for verification. I've not run into that situation yet. If -> you want an option for this use case, that's fine, (I'm all for +> you want an option for this use case, ?that's fine, (I'm all for > choice) but it should not be the default for IMA. Actually, we seem to have wandered away from the main concern which was -trying to select built in TPM drivers. What about a compromise: we +trying to select built in TPM drivers. ?What about a compromise: we already get the boot loader to do measurements and PCR extensions using the BIOS TPM driver, there's no reason why we can't do the same in the -early kernel until a real TPM driver is found. That way IMA would have +early kernel until a real TPM driver is found. ?That way IMA would have no dependency on any built in TPM driver ... is that an acceptable compromise to everyone? James + +-- +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 diff --git a/a/content_digest b/N1/content_digest index e14547d..430e0d0 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -12,30 +12,17 @@ "ref\01520897400.3547.253.camel@linux.vnet.ibm.com\0" "ref\01520899605.4522.67.camel@HansenPartnership.com\0" "ref\0BCA04D5D9A3B764C9B7405BBA4D4A3C002367FEF@ALPMBAPA12.e2k.ad.ge.com\0" - "From\0James Bottomley <James.Bottomley@hansenpartnership.com>\0" - "Subject\0Re: [PATCH] security: Fix IMA Kconfig for dependencies on ARM64\0" + "From\0James.Bottomley@hansenpartnership.com (James Bottomley)\0" + "Subject\0[PATCH] security: Fix IMA Kconfig for dependencies on ARM64\0" "Date\0Wed, 14 Mar 2018 07:41:11 -0700\0" - "To\0Safford" - David (GE Global Research - US) <david.safford@ge.com> - Mimi Zohar <zohar@linux.vnet.ibm.com> - Jiandi An <anjiandi@codeaurora.org> - " Jason Gunthorpe <jgg@ziepe.ca>\0" - "Cc\0dmitry.kasatkin@gmail.com <dmitry.kasatkin@gmail.com>" - jmorris@namei.org <jmorris@namei.org> - serge@hallyn.com <serge@hallyn.com> - linux-integrity@vger.kernel.org <linux-integrity@vger.kernel.org> - linux-ima-devel@lists.sourceforge.net <linux-ima-devel@lists.sourceforge.net> - linux-ima-user@lists.sourceforge.net <linux-ima-user@lists.sourceforge.net> - linux-security-module@vger.kernel.org <linux-security-module@vger.kernel.org> - " linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "On Tue, 2018-03-13 at 12:57 +0000, Safford, David (GE Global Research,\n" "US) wrote:\n" "> > \n" "> > -----Original Message-----\n" - "> > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com\n" + "> > From: James Bottomley [mailto:James.Bottomley at HansenPartnership.com\n" "> > ]\n" "> > Sent: Monday, March 12, 2018 8:07 PM\n" "> > To: Mimi Zohar <zohar@linux.vnet.ibm.com>; Jiandi An\n" @@ -49,7 +36,7 @@ "> > > everything accessed in the TCB.\n" "> > \n" "> > The initrd *is* part of the Trusted Computing Base because it's\n" - "> > part of the boot custody chain. That's really my point. If I\n" + "> > part of the boot custody chain. ?That's really my point. ?If I\n" "> > don't know what's in my initrd, I've broken the chain there and IMA\n" "> > can't fix it.\n" "> > \n" @@ -60,15 +47,15 @@ "> question.\n" "\n" "The point of deploying security measures is to make sure my system\n" - "isn't compromised. I realise the institutional view is \"we didn't\n" + "isn't compromised. ?I realise the institutional view is \"we didn't\n" "build the initrd\" and my individual view is well, I built my own kernel\n" - "as well, so what's the difference? But the initrd in both models is\n" + "as well, so what's the difference? ?But the initrd in both models is\n" "still part of the chain.\n" "\n" "> It's not signed as a whole by someone trusted. How can the\n" "> attestation server say a given hash of the initrd as a whole is good?\n" "\n" - "I trust myself. I can get the hash at build time. In the same way as\n" + "I trust myself. ?I can get the hash at build time. ?In the same way as\n" "I sign my own kernel at build time for secure boot.\n" "\n" "> If IMA is running from the very start, it can at least measure (and\n" @@ -83,17 +70,22 @@ "> Perhaps there is a use case where there is a known set of initrd\n" "> images, and so the bootloader's measurement of the initrd is\n" "> sufficient for verification. I've not run into that situation yet. If\n" - "> you want an option for this use case, that's fine, (I'm all for\n" + "> you want an option for this use case, ?that's fine, (I'm all for\n" "> choice) but it should not be the default for IMA.\n" "\n" "Actually, we seem to have wandered away from the main concern which was\n" - "trying to select built in TPM drivers. What about a compromise: we\n" + "trying to select built in TPM drivers. ?What about a compromise: we\n" "already get the boot loader to do measurements and PCR extensions using\n" "the BIOS TPM driver, there's no reason why we can't do the same in the\n" - "early kernel until a real TPM driver is found. That way IMA would have\n" + "early kernel until a real TPM driver is found. ?That way IMA would have\n" "no dependency on any built in TPM driver ... is that an acceptable\n" "compromise to everyone?\n" "\n" - James + "James\n" + "\n" + "--\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-security-module\" in\n" + "the body of a message to majordomo at vger.kernel.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -874fa9612d9cf009e590013c5cd3637ebdff75686d6a09aa6765e0550cccfb3d +e8024be6c3982bf46b65cc25825e4953d2f327951eb1879cc63d25d1a8ae827a
diff --git a/a/1.txt b/N2/1.txt index 0f30ed8..0128acc 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -16,7 +16,7 @@ US) wrote: > > > everything accessed in the TCB. > > > > The initrd *is* part of the Trusted Computing Base because it's -> > part of the boot custody chain. That's really my point. If I +> > part of the boot custody chain. That's really my point. If I > > don't know what's in my initrd, I've broken the chain there and IMA > > can't fix it. > > @@ -27,15 +27,15 @@ US) wrote: > question. The point of deploying security measures is to make sure my system -isn't compromised. I realise the institutional view is "we didn't +isn't compromised. I realise the institutional view is "we didn't build the initrd" and my individual view is well, I built my own kernel -as well, so what's the difference? But the initrd in both models is +as well, so what's the difference? But the initrd in both models is still part of the chain. > It's not signed as a whole by someone trusted. How can the > attestation server say a given hash of the initrd as a whole is good? -I trust myself. I can get the hash at build time. In the same way as +I trust myself. I can get the hash at build time. In the same way as I sign my own kernel at build time for secure boot. > If IMA is running from the very start, it can at least measure (and @@ -50,14 +50,14 @@ I sign my own kernel at build time for secure boot. > Perhaps there is a use case where there is a known set of initrd > images, and so the bootloader's measurement of the initrd is > sufficient for verification. I've not run into that situation yet. If -> you want an option for this use case, that's fine, (I'm all for +> you want an option for this use case, that's fine, (I'm all for > choice) but it should not be the default for IMA. Actually, we seem to have wandered away from the main concern which was -trying to select built in TPM drivers. What about a compromise: we +trying to select built in TPM drivers. What about a compromise: we already get the boot loader to do measurements and PCR extensions using the BIOS TPM driver, there's no reason why we can't do the same in the -early kernel until a real TPM driver is found. That way IMA would have +early kernel until a real TPM driver is found. That way IMA would have no dependency on any built in TPM driver ... is that an acceptable compromise to everyone? diff --git a/a/content_digest b/N2/content_digest index e14547d..94e7591 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -49,7 +49,7 @@ "> > > everything accessed in the TCB.\n" "> > \n" "> > The initrd *is* part of the Trusted Computing Base because it's\n" - "> > part of the boot custody chain. That's really my point. If I\n" + "> > part of the boot custody chain. \302\240That's really my point. \302\240If I\n" "> > don't know what's in my initrd, I've broken the chain there and IMA\n" "> > can't fix it.\n" "> > \n" @@ -60,15 +60,15 @@ "> question.\n" "\n" "The point of deploying security measures is to make sure my system\n" - "isn't compromised. I realise the institutional view is \"we didn't\n" + "isn't compromised. \302\240I realise the institutional view is \"we didn't\n" "build the initrd\" and my individual view is well, I built my own kernel\n" - "as well, so what's the difference? But the initrd in both models is\n" + "as well, so what's the difference? \302\240But the initrd in both models is\n" "still part of the chain.\n" "\n" "> It's not signed as a whole by someone trusted. How can the\n" "> attestation server say a given hash of the initrd as a whole is good?\n" "\n" - "I trust myself. I can get the hash at build time. In the same way as\n" + "I trust myself. \302\240I can get the hash at build time. \302\240In the same way as\n" "I sign my own kernel at build time for secure boot.\n" "\n" "> If IMA is running from the very start, it can at least measure (and\n" @@ -83,17 +83,17 @@ "> Perhaps there is a use case where there is a known set of initrd\n" "> images, and so the bootloader's measurement of the initrd is\n" "> sufficient for verification. I've not run into that situation yet. If\n" - "> you want an option for this use case, that's fine, (I'm all for\n" + "> you want an option for this use case, \302\240that's fine, (I'm all for\n" "> choice) but it should not be the default for IMA.\n" "\n" "Actually, we seem to have wandered away from the main concern which was\n" - "trying to select built in TPM drivers. What about a compromise: we\n" + "trying to select built in TPM drivers. \302\240What about a compromise: we\n" "already get the boot loader to do measurements and PCR extensions using\n" "the BIOS TPM driver, there's no reason why we can't do the same in the\n" - "early kernel until a real TPM driver is found. That way IMA would have\n" + "early kernel until a real TPM driver is found. \302\240That way IMA would have\n" "no dependency on any built in TPM driver ... is that an acceptable\n" "compromise to everyone?\n" "\n" James -874fa9612d9cf009e590013c5cd3637ebdff75686d6a09aa6765e0550cccfb3d +03c004b6dddf11907a2a1068be7f409e44fec44a789caf0ff1ddb84b0f46a8c8
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.