| Message ID | 20170725154423.24845-12-roberto.sassu@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 7/25/2017 11:44 AM, Roberto Sassu wrote: > Don't report measurements if the file digest has been included in > an uploaded digest list. > > The advantage of this solution is that the boot time overhead, when > a TPM is available, is very small because a PCR is extended only > for unknown files. The disadvantage is that verifiers do not know > anymore which and when files are accessed (they must assume that > the worst case happened, i.e. all files have been accessed). Am I reading this correctly that you want to measure certain files, but not ones that have been included in a "digest list", which sounds like a white list of sorts. If so, I have two concerns: 1 - How would the client get this digest list? Shouldn't it be up to the relying party to decide what is trusted and not trusted, not the client? What of the case with two different relying parties that have a different list of trusted applications? E.g., one trusts any version of program X, while the other trusts only version 3.1 and up? 2 - What about files on the digest list that were not run? The relying party may want to know if a program wasn't run? E.g., antivirus or a firewall. If the rule is "don't measure if it's on the digest list", how does the relying party know if it was run?
On 8/9/2017 10:36 PM, Ken Goldman wrote: > On 7/25/2017 11:44 AM, Roberto Sassu wrote: >> Don't report measurements if the file digest has been included in >> an uploaded digest list. >> >> The advantage of this solution is that the boot time overhead, when >> a TPM is available, is very small because a PCR is extended only >> for unknown files. The disadvantage is that verifiers do not know >> anymore which and when files are accessed (they must assume that >> the worst case happened, i.e. all files have been accessed). > > Am I reading this correctly that you want to measure certain files, but > not ones that have been included in a "digest list", which sounds like a > white list of sorts. > > If so, I have two concerns: > > 1 - How would the client get this digest list? Shouldn't it be up to > the relying party to decide what is trusted and not trusted, not the > client? The client can get the digest list from the RPM database or the measurement list of a previous boot. A verifier still decides if the client is trusted or not, depending on what could be possibly accessed rather than what has been accessed. > What of the case with two different relying parties that have a > different list of trusted applications? E.g., one trusts any version of > program X, while the other trusts only version 3.1 and up? There are two ways to provide more accurate information (make the list of possibly accessed files closer to the list of accessed files): 1) use the measurement list of a previous boot as a source for the digest list 2) use the RPM database as a source for the digest lists, and load the headers of the latest version of RPMs and: load only the headers of RPMs including files that appear in the measurement list of a previous boot (this solution should be preferred to solution 1, as signature-based attestation can be done) > 2 - What about files on the digest list that were not run? The relying > party may want to know if a program wasn't run? E.g., antivirus or a > firewall. > > If the rule is "don't measure if it's on the digest list", how does the > relying party know if it was run? If a measurement list does not contain unknown digests, this means that no malicious software was loaded. But, if the measurement list contains the digest of an antivirus binary, this does not necessarily mean that it was loaded. Since PCR 10 can be extended from userspace, a malicious user can extend the PCR with the digest of a fake measurement entry reporting the loading of the antivirus. He can then add the fake entry to the measurement list before it is sent to verifiers, so that they won't notice the addition. A possible countermeasure to this attack would be to modify the TPM driver to refuse to extend the PCRs used by IMA. Then, IMA could be further extended to accept a list of digests of files that will be certainly used and to create a measurement entry only after all files have been accessed. Roberto > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c index c329549..e289b7c 100644 --- a/security/integrity/ima/ima_main.c +++ b/security/integrity/ima/ima_main.c @@ -253,6 +253,14 @@ static int process_measurement(struct file *file, char *buf, loff_t size, goto out_digsig; } + if (!ima_disable_digest_check) { + if (ima_lookup_loaded_digest(iint->ima_hash->digest)) { + action ^= IMA_MEASURE; + iint->flags |= IMA_MEASURED; + iint->measured_pcrs |= (0x1 << pcr); + } + } + if (!pathbuf) /* ima_rdwr_violation possibly pre-fetched */ pathname = ima_d_path(&file->f_path, &pathbuf, filename);
Don't report measurements if the file digest has been included in an uploaded digest list. The advantage of this solution is that the boot time overhead, when a TPM is available, is very small because a PCR is extended only for unknown files. The disadvantage is that verifiers do not know anymore which and when files are accessed (they must assume that the worst case happened, i.e. all files have been accessed). Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> --- security/integrity/ima/ima_main.c | 8 ++++++++ 1 file changed, 8 insertions(+)