diff for duplicates of <1496079158.3841.350.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index bed4095..d6e951f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -24,16 +24,16 @@ I'm really sorry Guileherme, but as I previously explained, IMA has many aspects to it - the original file measurements (IMA-measurement), file hash/signature appraisal (IMA-appraisal), and file audit messages (IMA-audit) used for security analytics/forensics, not the file system -auditing.??To namespace IMA properly requires addressing some +auditing. To namespace IMA properly requires addressing some underlying problems - securityfs, root privilege required for writing security xattrs, per namespace IMA keyring - to name a few. I understand wanting to namespace the appraisal aspect first, but when you asked me if anyone else is working on namespacing IMA at the moment, I suggested starting with the IMA-audit aspect for a -reason.??By beginning with the IMA-audit aspect, we could ignore, at +reason. By beginning with the IMA-audit aspect, we could ignore, at least for the time being, some of these underlying problems, but -define the basic namespacing architecture.??By jumping to namespacing +define the basic namespacing architecture. By jumping to namespacing the appraisal aspect, you've simply avoided addressing the IMA namespacing architecture issues, which need to be addressed. @@ -48,9 +48,9 @@ environments. For example, depending on the environment, namespaces can come and go frequently. In such an environment do we really want all the namespace measurements to be included in the system measurement list, or should each namespace have its own measurement -list???Should the namespace measurement policy be the same as the -system measurement policy???Should the namespace (container) owner be -allowed to modify their own policy???If a file matches a rule in both +list? Should the namespace measurement policy be the same as the +system measurement policy? Should the namespace (container) owner be +allowed to modify their own policy? If a file matches a rule in both the namespace and system policies, should the file measurement be in both the namespace and the system measurement lists? @@ -58,17 +58,17 @@ both the namespace and the system measurement lists? - IMA-appraisal Assuming the IMA appraisal policy requires file signatures, signatures -are verified based on the keys on the IMA keyring.??When discussing +are verified based on the keys on the IMA keyring. When discussing namespacing IMA-appraisal, we might want different sets of keys in different namespaces. This requires separate keyrings for each -namespace. ?In some use cases, we might want to include the keys on +namespace. In some use cases, we might want to include the keys on the system IMA keyring, while in other use cases we might not. Even if real root initially installs the files with their file signatures, stored as extended attributes, how will software be updated, as writing file signatures requires root privilege?Capabilities has recently added support to permit root in -the namespace to write security.capability.??Similarly when +the namespace to write security.capability. Similarly when namespacing IMA, root in the namespace needs the ability to write security.ima. @@ -76,15 +76,15 @@ security.ima. - IMA-audit: The IMA-audit messages can augment other file system security -information used in security analytics/forensics.??This information +information used in security analytics/forensics. This information should be on a per namespace basis, meaning that each time a new file is accessed/executed, there needs to be a separate audit message, even -if a message already exists in another namespace.??Maintaining and +if a message already exists in another namespace. Maintaining and cleaning up this per namespace cache information, allows development of the IMA namespace architecture independently of other issues. -My original suggestion stands. ?Start with namespacing IMA- -audit.??Afterwards resolve the securityfs issues needed for +My original suggestion stands. Start with namespacing IMA- +audit. Afterwards resolve the securityfs issues needed for namespacing IMA-measurement, and subsequently resolve the keyring and xattr issues for namespacing IMA-appraisal. Although other subsystems have already addressed some of the issues listed here, the advice to @@ -98,8 +98,3 @@ As both Apparmor and IMA use securityfs for policy, it would be nice if their method for loading namespace policies would be similar too. 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 c937768..81c3d9e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,10 +4,26 @@ "ref\0d8d55872-db78-3535-a540-85c0dbb2d6fd@canonical.com\0" "ref\01495712762.3841.89.camel@linux.vnet.ibm.com\0" "ref\0CS1PR84MB0294089AC618EE12DB042263FFFF0@CS1PR84MB0294.NAMPRD84.PROD.OUTLOOK.COM\0" - "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0" - "Subject\0[RFC 04/11] ima: add support to namespace securityfs file\0" + "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" + "Subject\0Re: [RFC 04/11] ima: add support to namespace securityfs file\0" "Date\0Mon, 29 May 2017 13:32:38 -0400\0" - "To\0linux-security-module@vger.kernel.org\0" + "To\0Magalhaes" + Guilherme (Brazil R&D-CL) <guilherme.magalhaes@hpe.com> + John Johansen <john.johansen@canonical.com> + " dmitry.kasatkin@gmail.com <dmitry.kasatkin@gmail.com>\0" + "Cc\0viro@zeniv.linux.org.uk <viro@zeniv.linux.org.uk>" + james.l.morris@oracle.com <james.l.morris@oracle.com> + serge@hallyn.com <serge@hallyn.com> + linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org> + linux-kernel@vger.kernel.org <linux-kernel@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> + tycho@docker.com <tycho@docker.com> + Souza + Joaquim (Brazil R&D-ECL) <joaquims@hpe.com> + Edwards + " Nigel <nigel.edwards@hpe.com>\0" "\00:1\0" "b\0" "Hi Guilherme,\n" @@ -36,16 +52,16 @@ "many aspects to it - the original file measurements (IMA-measurement), \n" "file hash/signature appraisal (IMA-appraisal), and file audit messages\n" "(IMA-audit) used for security analytics/forensics, not the file system\n" - "auditing.??To namespace IMA properly requires addressing some\n" + "auditing.\302\240\302\240To namespace IMA properly requires addressing some\n" "underlying problems - securityfs, root privilege required for writing\n" "security xattrs, per namespace IMA keyring - to name a few.\n" "\n" "I understand wanting to namespace the appraisal aspect first, but when\n" "you asked me if anyone else is working on namespacing IMA at the\n" "moment, I suggested starting with the IMA-audit aspect for a\n" - "reason.??By beginning with the IMA-audit aspect, we could ignore, at\n" + "reason.\302\240\302\240By beginning with the IMA-audit aspect, we could ignore, at\n" "least for the time being, some of these underlying problems, but\n" - "define the basic namespacing architecture.??By jumping to namespacing\n" + "define the basic namespacing architecture.\302\240\302\240By jumping to namespacing\n" "the appraisal aspect, you've simply avoided addressing the IMA\n" "namespacing architecture issues, which need to be addressed.\n" "\n" @@ -60,9 +76,9 @@ "can come and go frequently. In such an environment do we really want\n" "all the namespace measurements to be included in the system\n" "measurement list, or should each namespace have its own measurement\n" - "list???Should the namespace measurement policy be the same as the\n" - "system measurement policy???Should the namespace (container) owner be\n" - "allowed to modify their own policy???If a file matches a rule in both\n" + "list?\302\240\302\240Should the namespace measurement policy be the same as the\n" + "system measurement policy?\302\240\302\240Should the namespace (container) owner be\n" + "allowed to modify their own policy?\302\240\302\240If a file matches a rule in both\n" "the namespace and system policies, should the file measurement be in\n" "both the namespace and the system measurement lists?\n" "\n" @@ -70,17 +86,17 @@ "- IMA-appraisal\n" "\n" "Assuming the IMA appraisal policy requires file signatures, signatures\n" - "are verified based on the keys on the IMA keyring.??When discussing\n" + "are verified based on the keys on the IMA keyring.\302\240\302\240When discussing\n" "namespacing IMA-appraisal, we might want different sets of keys in\n" "different namespaces. This requires separate keyrings for each\n" - "namespace. ?In some use cases, we might want to include the keys on\n" + "namespace. \302\240In some use cases, we might want to include the keys on\n" "the system IMA keyring, while in other use cases we might not.\n" "\n" "Even if real root initially installs the files with their file\n" "signatures, stored as extended attributes, how will software be\n" "updated, as writing file signatures requires root\n" "privilege?Capabilities has recently added support to permit root in\n" - "the namespace to write security.capability.??Similarly when\n" + "the namespace to write security.capability.\302\240\302\240Similarly when\n" "namespacing IMA, root in the namespace needs the ability to write\n" "security.ima.\n" "\n" @@ -88,15 +104,15 @@ "- IMA-audit:\n" "\n" "The IMA-audit messages can augment other file system security\n" - "information used in security analytics/forensics.??This information\n" + "information used in security analytics/forensics.\302\240\302\240This information\n" "should be on a per namespace basis, meaning that each time a new file\n" "is accessed/executed, there needs to be a separate audit message, even\n" - "if a message already exists in another namespace.??Maintaining and\n" + "if a message already exists in another namespace.\302\240\302\240Maintaining and\n" "cleaning up this per namespace cache information, allows development\n" "of the IMA namespace architecture independently of other issues.\n" "\n" - "My original suggestion stands. ?Start with namespacing IMA-\n" - "audit.??Afterwards resolve the securityfs issues needed for\n" + "My original suggestion stands. \302\240Start with namespacing IMA-\n" + "audit.\302\240\302\240Afterwards resolve the securityfs issues needed for\n" "namespacing IMA-measurement, and subsequently resolve the keyring and\n" "xattr issues for namespacing IMA-appraisal. Although other subsystems\n" "have already addressed some of the issues listed here, the advice to\n" @@ -109,11 +125,6 @@ "As both Apparmor and IMA use securityfs for policy, it would be nice\n" "if their method for loading namespace policies would be similar too.\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 -0e63ba14d58d8b680042f0022be1aac61aae1ae13d9ef85386254bd0c3c66f9a +6d74390e0b8262ef0e5a394a219c9f2088340d16f6ba9b6e8a840028621fe4f6
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.