diff for duplicates of <1510926170.5920.80.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 6850763..40172ac 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -20,7 +20,7 @@ On Fri, 2017-11-17 at 13:20 +0100, Roberto Sassu wrote: > >> i_uid = 0 and files with missing/invalid HMAC and i_uid != 0, at the > >> same time. > > -> > The LSMs are responsible for protecting their own labels. Theyhave +> > The LSMs are responsible for protecting their own labels.??Theyhave > > the opportunity to verify and deny access to files based on LSM > > labels, BEFORE IMA-appraisal is called to verify the file's integrity. > @@ -31,9 +31,9 @@ fully aware of the context of this discussion, that the discussion is not relevant to the "lockdown" patch set. Kernel modules, the kexec image, IMA policy and firmware call the pre -and post LSM kernel_read_file hooks. For these LSM hooks, IMA policy +and post LSM kernel_read_file hooks. ?For these LSM hooks, IMA policy rules are not written in terms of LSM labels or any other file -metadata. File signatures will always be appraised. +metadata. ?File signatures will always be appraised. > LSMs are responsible to enforce a security policy at run-time, while > IMA/EVM protect data and metadata against offline attacks. However, if @@ -45,13 +45,13 @@ metadata. File signatures will always be appraised. > security policy allows that application to modify files which are not > appraised by IMA. Only the database is appraised. -This use case scenario is really strange. The IMA policy should be +This use case scenario is really strange. ?The IMA policy should be verifying the integrity of the application that is allowed to modify the database, not the database. >From my limited knowledge of databases, databases tend to manage data caching themselves at the application level (eg. Direct IO), and avoid -file buffer caching. Having IMA calculate the file hash, would negate +file buffer caching. ?Having IMA calculate the file hash, would negate the performance benefits of doing their own data caching. > Then, the integrity of the database cannot be guaranteed anymore. When @@ -108,3 +108,8 @@ databases. I'd be interested in hearing what other people think. 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 61d9856..e1d32f2 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -8,16 +8,10 @@ "ref\08bbaea89-336c-d14b-2ed8-44cd0a0d3ed1@huawei.com\0" "ref\01510837595.3711.420.camel@linux.vnet.ibm.com\0" "ref\0a88aff89-1e75-9019-4394-640f5fb318da@huawei.com\0" - "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" - "Subject\0Re: IMA appraisal master plan?\0" + "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0" + "Subject\0IMA appraisal master plan?\0" "Date\0Fri, 17 Nov 2017 08:42:50 -0500\0" - "To\0Roberto Sassu <roberto.sassu@huawei.com>" - Matthew Garrett <mjg59@google.com> - " James Morris <james.l.morris@oracle.com>\0" - "Cc\0Patrick Ohly <patrick.ohly@intel.com>" - linux-integrity <linux-integrity@vger.kernel.org> - linux-security-module <linux-security-module@vger.kernel.org> - " Silviu Vlasceanu <silviu.vlasceanu@huawei.com>\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "On Fri, 2017-11-17 at 13:20 +0100, Roberto Sassu wrote:\n" @@ -42,7 +36,7 @@ "> >> i_uid = 0 and files with missing/invalid HMAC and i_uid != 0, at the\n" "> >> same time.\n" "> > \n" - "> > The LSMs are responsible for protecting their own labels. Theyhave\n" + "> > The LSMs are responsible for protecting their own labels.??Theyhave\n" "> > the opportunity to verify and deny access to files based on LSM\n" "> > labels, BEFORE IMA-appraisal is called to verify the file's integrity.\n" "> \n" @@ -53,9 +47,9 @@ "not relevant to the \"lockdown\" patch set.\n" "\n" "Kernel modules, the kexec image, IMA policy and firmware call the pre\n" - "and post LSM kernel_read_file hooks. For these LSM hooks, IMA policy\n" + "and post LSM kernel_read_file hooks. ?For these LSM hooks, IMA policy\n" "rules are not written in terms of LSM labels or any other file\n" - "metadata. File signatures will always be appraised.\n" + "metadata. ?File signatures will always be appraised.\n" "\n" "> LSMs are responsible to enforce a security policy at run-time, while\n" "> IMA/EVM protect data and metadata against offline attacks. However, if\n" @@ -67,13 +61,13 @@ "> security policy allows that application to modify files which are not\n" "> appraised by IMA. Only the database is appraised.\n" "\n" - "This use case scenario is really strange. The IMA policy should be\n" + "This use case scenario is really strange. ?The IMA policy should be\n" "verifying the integrity of the application that is allowed to modify\n" "the database, not the database.\n" "\n" ">From my limited knowledge of databases, databases tend to manage data\n" "caching themselves at the application level (eg. Direct IO), and avoid\n" - "file buffer caching. Having IMA calculate the file hash, would negate\n" + "file buffer caching. ?Having IMA calculate the file hash, would negate\n" "the performance benefits of doing their own data caching.\n" "\n" "> Then, the integrity of the database cannot be guaranteed anymore. When\n" @@ -129,6 +123,11 @@ "\n" "I'd be interested in hearing what other people think.\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 -7fb4af8e5a5814df684e7dc146769b2b612eb8e603ea76aafe50287e7ad5e6eb +92c58a249d8779189f552456a73b2c3a7882d5d7965f639a55212fd9814b4c49
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.