diff for duplicates of <1501166369.28419.171.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index fc5dffa..ed303d1 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -69,9 +69,9 @@ CL) wrote: > > > > > > > > > > Shouldn't it be both? > > > > -> > > > The policy defines which files are measured. ?The namespace policy +> > > > The policy defines which files are measured. The namespace policy > > > > could be different than it's parent's policy, and the parent's -> > > > policy could be different than the native policy. ?Basically, file +> > > > policy could be different than the native policy. Basically, file > > > > measurements need to be added to the namespace measurement list, > > > > recursively, up to the native measurement list. > > > @@ -83,16 +83,16 @@ CL) wrote: > > > > Yes, as the file needs to be measured only in the ns1 policy, the > > measurement would exist in the ns1 measurement list, but not in the -> > ns2 measurement list. ?The pseudo code snippet below might help. +> > ns2 measurement list. The pseudo code snippet below might help. > > This algorithm is potentially extending a PCR in TPM multiple times > for a single file event under a given namespace and duplicating > entries. Any concerns with performance and memory footprint? Going forward we assume associated with each container will be a vTPM. -The namespace measurements will extend a vTPM. ?As the container comes +The namespace measurements will extend a vTPM. As the container comes and goes the associated measurement list, keyring, and vTPM will come -and go as well. ?For this reason, based on policy, the same file +and go as well. For this reason, based on policy, the same file measurement might appear in multiple measurement lists. > What is the reason to adding a measurement to multiple namespace @@ -104,12 +104,12 @@ measurement might appear in multiple measurement lists. > store this list considering the namespaces may have a short life and > be reused thousands of times? -Different scenarios have different requirements. ?You're assuming that +Different scenarios have different requirements. You're assuming that only the system owner is interested in the measurement list, not the container owner. The current builtin measurement policies measure everything executed -on the system and anything accessed by real root. ?The namespace +on the system and anything accessed by real root. The namespace policy would probably be similar, but instead of measuring files accessed by real root, it would be files accessed by root in the namespace. @@ -120,7 +120,7 @@ namespace. > the 'native'/initial namespace, the measurement is not added to the > native measurement list. -Correct. ?The policy controls what is included measured, appraised, +Correct. The policy controls what is included measured, appraised, and audited. > Each measurement entry in the list could have new fields to identify @@ -128,7 +128,7 @@ and audited. > others fields could be added to uniquely identify the namespace id. The more fields included in the measurement list, the more -measurements will be added to the measurement list. ?Wouldn't it be +measurements will be added to the measurement list. Wouldn't it be enough to know that a certain file has been accessed/executed on the system and base any analytics/forensics on the IMA-audit data. @@ -137,7 +137,7 @@ system and base any analytics/forensics on the IMA-audit data. > parent is applied and then the native/initial namespace should > always have a set policy. -We shouldn't assume measure, appraise, or audit by default. ?Just like +We shouldn't assume measure, appraise, or audit by default. Just like it is up to the native system to define a policy or if there is a policy, the "container" owner should define the policy, or if there is a policy. @@ -168,8 +168,3 @@ Mimi > > return result; > > > > Mimi - --- -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 6a2a8e7..3de1ec9 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -11,10 +11,21 @@ "ref\020170725210801.GA5628@mail.hallyn.com\0" "ref\01501018134.27413.66.camel@linux.vnet.ibm.com\0" "ref\0TU4PR84MB03021F7FDF1B89ECAA8F7FFFFFBE0@TU4PR84MB0302.NAMPRD84.PROD.OUTLOOK.COM\0" - "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0" - "Subject\0[Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA namespace support\0" + "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" + "Subject\0Re: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA namespace support\0" "Date\0Thu, 27 Jul 2017 10:39:29 -0400\0" - "To\0linux-security-module@vger.kernel.org\0" + "To\0Magalhaes" + Guilherme (Brazil R&D-CL) <guilherme.magalhaes@hpe.com> + " Serge E. Hallyn <serge@hallyn.com>\0" + "Cc\0Mehmet Kayaalp <mkayaalp@cs.binghamton.edu>" + Yuqiong Sun <sunyuqiong1988@gmail.com> + containers <containers@lists.linux-foundation.org> + linux-kernel <linux-kernel@vger.kernel.org> + David Safford <david.safford@ge.com> + James Bottomley <James.Bottomley@hansenpartnership.com> + linux-security-module <linux-security-module@vger.kernel.org> + ima-devel <linux-ima-devel@lists.sourceforge.net> + " Yuqiong Sun <suny@us.ibm.com>\0" "\00:1\0" "b\0" "On Thu, 2017-07-27 at 12:51 +0000, Magalhaes, Guilherme (Brazil R&D-\n" @@ -88,9 +99,9 @@ "> > > > >\n" "> > > > > Shouldn't it be both?\n" "> > > >\n" - "> > > > The policy defines which files are measured. ?The namespace policy\n" + "> > > > The policy defines which files are measured. \302\240The namespace policy\n" "> > > > could be different than it's parent's policy, and the parent's\n" - "> > > > policy could be different than the native policy. ?Basically, file\n" + "> > > > policy could be different than the native policy. \302\240Basically, file\n" "> > > > measurements need to be added to the namespace measurement list,\n" "> > > > recursively, up to the native measurement list.\n" "> > >\n" @@ -102,16 +113,16 @@ "> > \n" "> > Yes, as the file needs to be measured only in the ns1 policy, the\n" "> > measurement would exist in the ns1 measurement list, but not in the\n" - "> > ns2 measurement list. ?The pseudo code snippet below might help.\n" + "> > ns2 measurement list. \302\240The pseudo code snippet below might help.\n" "> \n" "> This algorithm is potentially extending a PCR in TPM multiple times\n" "> for a single file event under a given namespace and duplicating\n" "> entries. Any concerns with performance and memory footprint?\n" "\n" "Going forward we assume associated with each container will be a vTPM.\n" - "The namespace measurements will extend a vTPM. ?As the container comes\n" + "The namespace measurements will extend a vTPM. \302\240As the container comes\n" "and goes the associated measurement list, keyring, and vTPM will come\n" - "and go as well. ?For this reason, based on policy, the same file\n" + "and go as well. \302\240For this reason, based on policy, the same file\n" "measurement might appear in multiple measurement lists.\n" "\n" "> What is the reason to adding a measurement to multiple namespace\n" @@ -123,12 +134,12 @@ "> store this list considering the namespaces may have a short life and\n" "> be reused thousands of times?\n" "\n" - "Different scenarios have different requirements. ?You're assuming that\n" + "Different scenarios have different requirements. \302\240You're assuming that\n" "only the system owner is interested in the measurement list, not the\n" "container owner.\n" "\n" "The current builtin measurement policies measure everything executed\n" - "on the system and anything accessed by real root. ?The namespace\n" + "on the system and anything accessed by real root. \302\240The namespace\n" "policy would probably be similar, but instead of measuring files\n" "accessed by real root, it would be files accessed by root in the\n" "namespace.\n" @@ -139,7 +150,7 @@ "> the 'native'/initial namespace, the measurement is not added to the\n" "> native measurement list.\n" "\n" - "Correct. ?The policy controls what is included measured, appraised,\n" + "Correct. \302\240The policy controls what is included measured, appraised,\n" "and audited.\n" "\n" "> Each measurement entry in the list could have new fields to identify\n" @@ -147,7 +158,7 @@ "> others fields could be added to uniquely identify the namespace id.\n" "\n" "The more fields included in the measurement list, the more\n" - "measurements will be added to the measurement list. ?Wouldn't it be\n" + "measurements will be added to the measurement list. \302\240Wouldn't it be\n" "enough to know that a certain file has been accessed/executed on the\n" "system and base any analytics/forensics on the IMA-audit data.\n" "\n" @@ -156,7 +167,7 @@ "> parent is applied and then the native/initial namespace should\n" "> always have a set policy.\n" "\n" - "We shouldn't assume measure, appraise, or audit by default. ?Just like\n" + "We shouldn't assume measure, appraise, or audit by default. \302\240Just like\n" "it is up to the native system to define a policy or if there is a\n" "policy, the \"container\" owner should define the policy, or if there is\n" "a policy.\n" @@ -186,11 +197,6 @@ "> > \n" "> > return result;\n" "> > \n" - "> > Mimi\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 + > > Mimi -f99d377e91558859037b143cea33ee4ee82d5828dbd9cc720caffb84341de5e9 +e3e6c01b2403d7ffc1e5f7f5fc9e8fe3843807b40eb592b64bc68259a29d8ea6
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.