diff for duplicates of <1521049841.3547.500.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 3d56178..b047592 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -19,15 +19,15 @@ On Wed, 2018-03-14 at 11:17 -0500, Eric W. Biederman wrote: > that does not meet ima's requirements. Currently files on remote filesystems are measured/appraised/audited -once. With the new flags, our options would be to either fail the +once. ?With the new flags, our options would be to either fail the signature verification or constantly re-measure/re-appraise files on -remote file systems. Neither option seems like the right solution. +remote file systems. ?Neither option seems like the right solution. There's some very initial discussions on how to support file integrity -on remote filesystems. Chuck Lever has some thoughts on piggy-backing -on the fs-verity work being done. From a very, very high level, IMA- +on remote filesystems. ?Chuck Lever has some thoughts on piggy-backing +on the fs-verity work being done. ?From a very, very high level, IMA- appraisal would verify the file signature, but leave the integrity -enforcement to the vfs/fs layer. By integrating fs-verity or similar +enforcement to the vfs/fs layer. ?By integrating fs-verity or similar proposal with IMA, measurements would be included in the measurement list and keys used for file signature verification would use the same existing IMA-appraisal infrastructure. @@ -40,3 +40,8 @@ Right, like for fuse, I don't believe this existing hook works for remote filesystems. 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 5d37e31..450839d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,21 +3,10 @@ "ref\0CANXojczCU3UC4xsPYzAYqFW3_WR9Z7QO_exd4dB6eyQR2STuUg@mail.gmail.com\0" "ref\01521032461.3547.404.camel@linux.vnet.ibm.com\0" "ref\0877eqer5r6.fsf@xmission.com\0" - "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" - "Subject\0Re: [PATCH v3 4/4] fuse: define the filesystem as untrusted\0" + "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0" + "Subject\0[PATCH v3 4/4] fuse: define the filesystem as untrusted\0" "Date\0Wed, 14 Mar 2018 13:50:41 -0400\0" - "To\0Eric W. Biederman <ebiederm@xmission.com>\0" - "Cc\0Stef Bon <stefbon@gmail.com>" - linux-integrity@vger.kernel.org - linux-security-module@vger.kernel.org - linux-fsdevel@vger.kernel.org - Miklos Szeredi <miklos@szeredi.hu> - Seth Forshee <seth.forshee@canonical.com> - Dongsu Park <dongsu@kinvolk.io> - Alban Crequy <alban@kinvolk.io> - Serge E. Hallyn <serge@hallyn.com> - chuck Lever <chuck.lever@oracle.com> - " Michael Halcrow <mhalcrow@google.com>\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "On Wed, 2018-03-14 at 11:17 -0500, Eric W. Biederman wrote:\n" @@ -41,15 +30,15 @@ "> that does not meet ima's requirements.\n" "\n" "Currently files on remote filesystems are measured/appraised/audited\n" - "once. With the new flags, our options would be to either fail the\n" + "once. ?With the new flags, our options would be to either fail the\n" "signature verification or constantly re-measure/re-appraise files on\n" - "remote file systems. Neither option seems like the right solution.\n" + "remote file systems. ?Neither option seems like the right solution.\n" "\n" "There's some very initial discussions on how to support file integrity\n" - "on remote filesystems. Chuck Lever has some thoughts on piggy-backing \n" - "on the fs-verity work being done. From a very, very high level, IMA-\n" + "on remote filesystems. ?Chuck Lever has some thoughts on piggy-backing \n" + "on the fs-verity work being done. ?From a very, very high level, IMA-\n" "appraisal would verify the file signature, but leave the integrity\n" - "enforcement to the vfs/fs layer. By integrating fs-verity or similar\n" + "enforcement to the vfs/fs layer. ?By integrating fs-verity or similar\n" "proposal with IMA, measurements would be included in the measurement\n" "list and keys used for file signature verification would use the same\n" "existing IMA-appraisal infrastructure.\n" @@ -61,6 +50,11 @@ "Right, like for fuse, I don't believe this existing hook works for\n" "remote filesystems.\n" "\n" - Mimi + "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 -0b6ead5cc02f1ff7328d17969b742ed7053ca6b818ef3d4a51ea199ed8675a94 +a27fca7f98ab32c88f225f39a6bb64f69385c008cbc2b80c6934377b40e600de
diff --git a/a/1.txt b/N2/1.txt index 3d56178..a1a9b44 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -19,15 +19,15 @@ On Wed, 2018-03-14 at 11:17 -0500, Eric W. Biederman wrote: > that does not meet ima's requirements. Currently files on remote filesystems are measured/appraised/audited -once. With the new flags, our options would be to either fail the +once. With the new flags, our options would be to either fail the signature verification or constantly re-measure/re-appraise files on -remote file systems. Neither option seems like the right solution. +remote file systems. Neither option seems like the right solution. There's some very initial discussions on how to support file integrity -on remote filesystems. Chuck Lever has some thoughts on piggy-backing -on the fs-verity work being done. From a very, very high level, IMA- +on remote filesystems. Chuck Lever has some thoughts on piggy-backing +on the fs-verity work being done. From a very, very high level, IMA- appraisal would verify the file signature, but leave the integrity -enforcement to the vfs/fs layer. By integrating fs-verity or similar +enforcement to the vfs/fs layer. By integrating fs-verity or similar proposal with IMA, measurements would be included in the measurement list and keys used for file signature verification would use the same existing IMA-appraisal infrastructure. diff --git a/a/content_digest b/N2/content_digest index 5d37e31..031b24b 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -41,15 +41,15 @@ "> that does not meet ima's requirements.\n" "\n" "Currently files on remote filesystems are measured/appraised/audited\n" - "once. With the new flags, our options would be to either fail the\n" + "once. \302\240With the new flags, our options would be to either fail the\n" "signature verification or constantly re-measure/re-appraise files on\n" - "remote file systems. Neither option seems like the right solution.\n" + "remote file systems. \302\240Neither option seems like the right solution.\n" "\n" "There's some very initial discussions on how to support file integrity\n" - "on remote filesystems. Chuck Lever has some thoughts on piggy-backing \n" - "on the fs-verity work being done. From a very, very high level, IMA-\n" + "on remote filesystems. \302\240Chuck Lever has some thoughts on piggy-backing \n" + "on the fs-verity work being done. \302\240From a very, very high level, IMA-\n" "appraisal would verify the file signature, but leave the integrity\n" - "enforcement to the vfs/fs layer. By integrating fs-verity or similar\n" + "enforcement to the vfs/fs layer. \302\240By integrating fs-verity or similar\n" "proposal with IMA, measurements would be included in the measurement\n" "list and keys used for file signature verification would use the same\n" "existing IMA-appraisal infrastructure.\n" @@ -63,4 +63,4 @@ "\n" Mimi -0b6ead5cc02f1ff7328d17969b742ed7053ca6b818ef3d4a51ea199ed8675a94 +b84cfa8ac235594e1c3f7bcab78cd17ccd2a69e2fc73a6c3fda150c511274bcc
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.