diff for duplicates of <1521139535.5348.89.camel@HansenPartnership.com> diff --git a/a/1.txt b/N1/1.txt index 4819386..a64e7fb 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -11,7 +11,7 @@ On Thu, 2018-03-15 at 14:26 -0400, Stefan Berger wrote: > > mount_ns. > > > > When we had this discussion last year, we talked about possibly -> > using the user_ns instead. It makes sense because for IMA +> > using the user_ns instead.??It makes sense because for IMA > > signatures you're > > 'using the user_ns' I suppose means hooking IMA namespace to it... @@ -27,9 +27,9 @@ user_ns. > > > > commit f36f8c75ae2e7d4da34f4c908cebdb4aa42c977e > > Author: David Howells <dhowells@redhat.com> -> > Date: Tue Sep 24 10:35:19 2013 +0100 +> > Date:???Tue Sep 24 10:35:19 2013 +0100 > > -> > KEYS: Add per-user_namespace registers for persistent per-UID +> > ?????KEYS: Add per-user_namespace registers for persistent per-UID > > kerberos caches > > The benefit for IMA would be that this would then tie the keys needed @@ -38,22 +38,22 @@ user_ns. > is now hooked to the user namespace, and you join that user namespace > but your files don't have signatures, nothing will execute anymore. > That's now a side effect of joining this user namespace unless we -> have a magic exception. My feeling is, people may not like that... +> have a magic ?exception. My feeling is, people may not like that... Agree, but I think the magic might be to populate the ima keyring with -the parent on user_ns creation. That way the user_ns owner can delete +the parent on user_ns creation. ?That way the user_ns owner can delete the parent keys if they don't like them, but by default the parent appraisal policy should just work. > > > > I saw that Serge even recently mentioned that you need to take -> > > > this aspect of the changes back to the drawing board. With my +> > > > this aspect of the changes back to the drawing board.??With my > > > > namespace maintainer hat on I repeat that. > > > Drawing board is here now (tuning on the text...): > > > > > > http://kernsec.org/wiki/index.php/IMA_Namespacing_design_consider > > > ations > > You mention an abuse case here which is basically a way of relaxing -> > security policy. Cannot we fix that by making policy hierarchical, +> > security policy.??Cannot we fix that by making policy hierarchical, > > so a child namespace must have the same or a more strict policy > > than the parent? > @@ -72,3 +72,8 @@ containers (i.e. containers which run real root) would be unable to have their own IMA namespace ... that's also going to be surprising. 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 f2d4f79..ab54320 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,20 +4,10 @@ "ref\0c18b6e92-57f0-5994-eb60-5fadc6671832@linux.vnet.ibm.com\0" "ref\01521135192.5348.64.camel@HansenPartnership.com\0" "ref\02183a3b4-6270-d2e9-70ad-a7399eb1681c@linux.vnet.ibm.com\0" - "From\0James Bottomley <James.Bottomley@hansenpartnership.com>\0" - "Subject\0Re: [RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support\0" + "From\0James.Bottomley@hansenpartnership.com (James Bottomley)\0" + "Subject\0[RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support\0" "Date\0Thu, 15 Mar 2018 11:45:35 -0700\0" - "To\0Stefan Berger <stefanb@linux.vnet.ibm.com>" - " Eric W. Biederman <ebiederm@xmission.com>\0" - "Cc\0mkayaalp@cs.binghamton.edu" - Mehmet Kayaalp <mkayaalp@linux.vnet.ibm.com> - sunyuqiong1988@gmail.com - containers@lists.linux-foundation.org - linux-kernel@vger.kernel.org - david.safford@ge.com - linux-security-module@vger.kernel.org - linux-integrity@vger.kernel.org - " zohar@linux.vnet.ibm.com\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "On Thu, 2018-03-15 at 14:26 -0400, Stefan Berger wrote:\n" @@ -33,7 +23,7 @@ "> > mount_ns.\n" "> > \n" "> > When we had this discussion last year, we talked about possibly\n" - "> > using the user_ns instead. It makes sense because for IMA\n" + "> > using the user_ns instead.??It makes sense because for IMA\n" "> > signatures you're\n" "> \n" "> 'using the user_ns' I suppose means hooking IMA namespace to it...\n" @@ -49,9 +39,9 @@ "> > \n" "> > commit f36f8c75ae2e7d4da34f4c908cebdb4aa42c977e\n" "> > Author: David Howells <dhowells@redhat.com>\n" - "> > Date: Tue Sep 24 10:35:19 2013 +0100\n" + "> > Date:???Tue Sep 24 10:35:19 2013 +0100\n" "> > \n" - "> > KEYS: Add per-user_namespace registers for persistent per-UID\n" + "> > ?????KEYS: Add per-user_namespace registers for persistent per-UID\n" "> > kerberos caches\n" "> \n" "> The benefit for IMA would be that this would then tie the keys needed\n" @@ -60,22 +50,22 @@ "> is now hooked to the user namespace, and you join that user namespace\n" "> but your files don't have signatures, nothing will execute anymore.\n" "> That's now a side effect of joining this user namespace unless we\n" - "> have a magic exception. My feeling is, people may not like that...\n" + "> have a magic ?exception. My feeling is, people may not like that...\n" "\n" "Agree, but I think the magic might be to populate the ima keyring with\n" - "the parent on user_ns creation. That way the user_ns owner can delete\n" + "the parent on user_ns creation. ?That way the user_ns owner can delete\n" "the parent keys if they don't like them, but by default the parent\n" "appraisal policy should just work.\n" "\n" "> > > > I saw that Serge even recently mentioned that you need to take\n" - "> > > > this aspect of the changes back to the drawing board. With my\n" + "> > > > this aspect of the changes back to the drawing board.??With my\n" "> > > > namespace maintainer hat on I repeat that.\n" "> > > Drawing board is here now (tuning on the text...):\n" "> > > \n" "> > > http://kernsec.org/wiki/index.php/IMA_Namespacing_design_consider\n" "> > > ations\n" "> > You mention an abuse case here which is basically a way of relaxing\n" - "> > security policy. Cannot we fix that by making policy hierarchical,\n" + "> > security policy.??Cannot we fix that by making policy hierarchical,\n" "> > so a child namespace must have the same or a more strict policy\n" "> > than the parent?\n" "> \n" @@ -93,6 +83,11 @@ "containers (i.e. containers which run real root) would be unable to\n" "have their own IMA namespace ... that's also going to be surprising.\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 -d028e58cf42d8c803f19f2aeeb799d7b424389d56b11d87400b9f1adeb40c7a6 +9bc1772e2ad23de3357ccb38decb78aa6aaf78bf4c0ba5460e1c32129563e858
diff --git a/a/1.txt b/N2/1.txt index 4819386..fb9dc15 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -11,7 +11,7 @@ On Thu, 2018-03-15 at 14:26 -0400, Stefan Berger wrote: > > mount_ns. > > > > When we had this discussion last year, we talked about possibly -> > using the user_ns instead. It makes sense because for IMA +> > using the user_ns instead. It makes sense because for IMA > > signatures you're > > 'using the user_ns' I suppose means hooking IMA namespace to it... @@ -27,9 +27,9 @@ user_ns. > > > > commit f36f8c75ae2e7d4da34f4c908cebdb4aa42c977e > > Author: David Howells <dhowells@redhat.com> -> > Date: Tue Sep 24 10:35:19 2013 +0100 +> > Date: Tue Sep 24 10:35:19 2013 +0100 > > -> > KEYS: Add per-user_namespace registers for persistent per-UID +> > KEYS: Add per-user_namespace registers for persistent per-UID > > kerberos caches > > The benefit for IMA would be that this would then tie the keys needed @@ -38,22 +38,22 @@ user_ns. > is now hooked to the user namespace, and you join that user namespace > but your files don't have signatures, nothing will execute anymore. > That's now a side effect of joining this user namespace unless we -> have a magic exception. My feeling is, people may not like that... +> have a magic exception. My feeling is, people may not like that... Agree, but I think the magic might be to populate the ima keyring with -the parent on user_ns creation. That way the user_ns owner can delete +the parent on user_ns creation. That way the user_ns owner can delete the parent keys if they don't like them, but by default the parent appraisal policy should just work. > > > > I saw that Serge even recently mentioned that you need to take -> > > > this aspect of the changes back to the drawing board. With my +> > > > this aspect of the changes back to the drawing board. With my > > > > namespace maintainer hat on I repeat that. > > > Drawing board is here now (tuning on the text...): > > > > > > http://kernsec.org/wiki/index.php/IMA_Namespacing_design_consider > > > ations > > You mention an abuse case here which is basically a way of relaxing -> > security policy. Cannot we fix that by making policy hierarchical, +> > security policy. Cannot we fix that by making policy hierarchical, > > so a child namespace must have the same or a more strict policy > > than the parent? > diff --git a/a/content_digest b/N2/content_digest index f2d4f79..a847914 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -33,7 +33,7 @@ "> > mount_ns.\n" "> > \n" "> > When we had this discussion last year, we talked about possibly\n" - "> > using the user_ns instead. It makes sense because for IMA\n" + "> > using the user_ns instead.\302\240\302\240It makes sense because for IMA\n" "> > signatures you're\n" "> \n" "> 'using the user_ns' I suppose means hooking IMA namespace to it...\n" @@ -49,9 +49,9 @@ "> > \n" "> > commit f36f8c75ae2e7d4da34f4c908cebdb4aa42c977e\n" "> > Author: David Howells <dhowells@redhat.com>\n" - "> > Date: Tue Sep 24 10:35:19 2013 +0100\n" + "> > Date:\302\240\302\240\302\240Tue Sep 24 10:35:19 2013 +0100\n" "> > \n" - "> > KEYS: Add per-user_namespace registers for persistent per-UID\n" + "> > \302\240\302\240\302\240\302\240\302\240KEYS: Add per-user_namespace registers for persistent per-UID\n" "> > kerberos caches\n" "> \n" "> The benefit for IMA would be that this would then tie the keys needed\n" @@ -60,22 +60,22 @@ "> is now hooked to the user namespace, and you join that user namespace\n" "> but your files don't have signatures, nothing will execute anymore.\n" "> That's now a side effect of joining this user namespace unless we\n" - "> have a magic exception. My feeling is, people may not like that...\n" + "> have a magic \302\240exception. My feeling is, people may not like that...\n" "\n" "Agree, but I think the magic might be to populate the ima keyring with\n" - "the parent on user_ns creation. That way the user_ns owner can delete\n" + "the parent on user_ns creation. \302\240That way the user_ns owner can delete\n" "the parent keys if they don't like them, but by default the parent\n" "appraisal policy should just work.\n" "\n" "> > > > I saw that Serge even recently mentioned that you need to take\n" - "> > > > this aspect of the changes back to the drawing board. With my\n" + "> > > > this aspect of the changes back to the drawing board.\302\240\302\240With my\n" "> > > > namespace maintainer hat on I repeat that.\n" "> > > Drawing board is here now (tuning on the text...):\n" "> > > \n" "> > > http://kernsec.org/wiki/index.php/IMA_Namespacing_design_consider\n" "> > > ations\n" "> > You mention an abuse case here which is basically a way of relaxing\n" - "> > security policy. Cannot we fix that by making policy hierarchical,\n" + "> > security policy.\302\240\302\240Cannot we fix that by making policy hierarchical,\n" "> > so a child namespace must have the same or a more strict policy\n" "> > than the parent?\n" "> \n" @@ -95,4 +95,4 @@ "\n" James -d028e58cf42d8c803f19f2aeeb799d7b424389d56b11d87400b9f1adeb40c7a6 +9ccf4de66085c869b2da6ad6adad8b1447c4d8c89cb37f9a4727bebf4f42703e
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.