Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752703AbdHBRnH (ORCPT ); Wed, 2 Aug 2017 13:43:07 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:45973 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752564AbdHBRnF (ORCPT ); Wed, 2 Aug 2017 13:43:05 -0400 References: <20170706221753.17380-1-bauerman@linux.vnet.ibm.com> <20170706221753.17380-8-bauerman@linux.vnet.ibm.com> <1501424988.9230.67.camel@linux.vnet.ibm.com> From: Thiago Jung Bauermann To: Mimi Zohar Cc: linux-security-module@vger.kernel.org, linux-ima-devel@lists.sourceforge.net, keyrings@vger.kernel.org, linux-crypto@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Dmitry Kasatkin , James Morris , "Serge E. Hallyn" , David Howells , David Woodhouse , Jessica Yu , Rusty Russell , Herbert Xu , "David S. Miller" , "AKASHI\, Takahiro" Subject: Re: [PATCH v3 7/7] ima: Support module-style appended signatures for appraisal In-reply-to: <1501424988.9230.67.camel@linux.vnet.ibm.com> Date: Wed, 02 Aug 2017 14:42:47 -0300 MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-MML: disable x-cbid: 17080217-0020-0000-0000-00000C7AF444 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007472; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000216; SDB=6.00896578; UDB=6.00448530; IPR=6.00676765; BA=6.00005506; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016500; XFM=3.00000015; UTC=2017-08-02 17:43:02 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17080217-0021-0000-0000-00005D883F9C Message-Id: <87fud9yig8.fsf@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-08-02_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=5 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708020285 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 7625 Lines: 201 Mimi Zohar writes: > On Thu, 2017-07-06 at 19:17 -0300, Thiago Jung Bauermann wrote: >> --- a/security/integrity/ima/ima_appraise.c >> +++ b/security/integrity/ima/ima_appraise.c >> @@ -200,18 +200,40 @@ int ima_read_xattr(struct dentry *dentry, >> */ >> int ima_appraise_measurement(enum ima_hooks func, >> struct integrity_iint_cache *iint, >> - struct file *file, const unsigned char *filename, >> - struct evm_ima_xattr_data *xattr_value, >> - int xattr_len, int opened) >> + struct file *file, const void *buf, loff_t size, >> + const unsigned char *filename, >> + struct evm_ima_xattr_data **xattr_value_, >> + int *xattr_len_, int opened) >> { >> static const char op[] = "appraise_data"; >> char *cause = "unknown"; >> struct dentry *dentry = file_dentry(file); >> struct inode *inode = d_backing_inode(dentry); >> enum integrity_status status = INTEGRITY_UNKNOWN; >> - int rc = xattr_len, hash_start = 0; >> + struct evm_ima_xattr_data *xattr_value = *xattr_value_; >> + int xattr_len = *xattr_len_, rc = xattr_len, hash_start = 0; >> + bool appraising_modsig = false; >> + void *xattr_value_evm; >> + size_t xattr_len_evm; >> + >> + if (iint->flags & IMA_MODSIG_ALLOWED) { >> + /* >> + * Not supposed to happen. Hooks that support modsig are >> + * whitelisted when parsing the policy using >> + * ima_hooks_supports_modsig. >> + */ >> + if (!buf || !size) >> + WARN_ONCE(true, "%s doesn't support modsig\n", >> + func_tokens[func]); > > ima _appraise_measurement() is getting kind of long. Is there any > reason we can't move this comment and test to ima_read_modsig()? I didn't do that because then I would need to pass func as an argument to ima_read_modsig just to print the warning above. But it does simplify the code so it may be worth it. I'll make that change in v4. >> @@ -229,8 +251,24 @@ int ima_appraise_measurement(enum ima_hooks func, >> goto out; >> } >> >> - status = evm_verifyxattr(dentry, XATTR_NAME_IMA, xattr_value, rc, iint); >> - if ((status != INTEGRITY_PASS) && (status != INTEGRITY_UNKNOWN)) { >> + /* >> + * Appended signatures aren't protected by EVM but we still call >> + * evm_verifyxattr to check other security xattrs, if they exist. >> + */ >> + if (appraising_modsig) { >> + xattr_value_evm = NULL; >> + xattr_len_evm = 0; >> + } else { >> + xattr_value_evm = xattr_value; >> + xattr_len_evm = xattr_len; >> + } >> + >> + status = evm_verifyxattr(dentry, XATTR_NAME_IMA, xattr_value_evm, >> + xattr_len_evm, iint); >> + if (appraising_modsig && status == INTEGRITY_FAIL) { >> + cause = "invalid-HMAC"; >> + goto out; > > "modsig" is special, because having any security xattrs is not > required. This test doesn't prevent status from being set to > "missing-HMAC". This test is redundant with the original tests below. Indeed, that is wrong. I'm still a bit fuzzy about how EVM works and how it interacts with IMA. The only way I can think of singling out modsig without reintroduced the complex expression you didn't like in v2 is as below. What do you think? @@ -229,8 +241,25 @@ int ima_appraise_measurement(enum ima_hooks func, goto out; } - status = evm_verifyxattr(dentry, XATTR_NAME_IMA, xattr_value, rc, iint); - if ((status != INTEGRITY_PASS) && (status != INTEGRITY_UNKNOWN)) { + /* + * Appended signatures aren't protected by EVM but we still call + * evm_verifyxattr to check other security xattrs, if they exist. + */ + if (appraising_modsig) { + xattr_value_evm = NULL; + xattr_len_evm = 0; + } else { + xattr_value_evm = xattr_value; + xattr_len_evm = xattr_len; + } + + status = evm_verifyxattr(dentry, XATTR_NAME_IMA, xattr_value_evm, + xattr_len_evm, iint); + if (appraising_modsig && (status == INTEGRITY_NOLABEL + || status == INTEGRITY_NOXATTRS)) + /* It's ok if there's no xattr in the case of modsig. */ + ; + else if (status != INTEGRITY_PASS && status != INTEGRITY_UNKNOWN) { if ((status == INTEGRITY_NOLABEL) || (status == INTEGRITY_NOXATTRS)) cause = "missing-HMAC"; >> + } else if (status != INTEGRITY_PASS && status != INTEGRITY_UNKNOWN) { >> if ((status == INTEGRITY_NOLABEL) >> || (status == INTEGRITY_NOXATTRS)) >> cause = "missing-HMAC"; >> @@ -281,6 +319,43 @@ int ima_appraise_measurement(enum ima_hooks func, >> status = INTEGRITY_PASS; >> } > > Calling evm_verifyxattr() with the IMA xattr value prevents EVM from > having to re-read the IMA xattr, but isn't necessary.On modsig > signature verification failure, calling evm_verifyxattr() a second > time isn't necessary. So even for the IMA xattr sig case, the evm_verifyxattr call in ima_appraise_measurement is an optimization and can be skipped? >> + case IMA_MODSIG: >> + /* >> + * To avoid being tricked into recursion, we don't allow a >> + * modsig stored in the xattr. >> + */ >> + if (!appraising_modsig) { >> + status = INTEGRITY_UNKNOWN; >> + cause = "unknown-ima-data"; >> + >> + break; >> + } >> + >> + rc = ima_modsig_verify(INTEGRITY_KEYRING_IMA, xattr_value); >> + if (!rc) { >> + iint->flags |= IMA_DIGSIG; >> + status = >> + >> + kfree(*xattr_value_); >> + *xattr_value_ = xattr_value; >> + *xattr_len_ = xattr_len; >> + >> + break; >> + } > > When including the appended signature in the measurement list, the > corresponding file hash needs to be included in the measurement list, > which might be different than the previously calculated file hash > based on the hash algorithm as defined in the IMA xattr. > > Including the file hash and signature in the measurement list allows > the attestation server, with just a public key, to verify the file > signature against the file hash. No need for a white list. > > ima_modsig_verify() must calculate the file hash in order to verify > the file signature. This file hash value somehow needs to be returned > in order for it to be included in the measurement list. In that case, patch 6/7 "ima: Store measurement after appraisal" isn't enough and we have to go back to v2's change in ima_main.c which ties together the collect and appraise steps in process_measurement (In that version I called the function measure_and_appraise but it should be called collect_and_appraise instead). That is because if the modsig verification fails, the hash needs to be recalculated for the xattr signature verification. Either that, or I add another call to ima_collect_measurement inside ima_appraise_measurement if the modsig verification fails. Which do you prefer? >> + /* >> + * The appended signature failed verification. Let's try >> + * reading a signature from the extended attribute instead. >> + */ >> + >> + pr_debug("modsig didn't verify, trying the xattr signature\n"); >> + >> + ima_free_xattr_data(xattr_value); >> + iint->flags &= ~IMA_MODSIG_ALLOWED; >> + >> + return ima_appraise_measurement(func, iint, file, buf, size, >> + filename, xattr_value_, >> + xattr_len_, opened); > > Most of the code before "switch" needs to be done only once. Is > recursion necessary? Or can we just retry the "switch" using the IMA > xattr, assuming there is an IMA xattr? I used recursion to avoid duplicating two blocks of code: the logic in the "if (rc <= 0)" block which needs to be done again when verifying the xattr sig, and also the logic of interpreting the return value of evm_verifyxattr which I also thought needed to be done again, but you seem to be saying that is just an optimization and can be skipped. -- Thiago Jung Bauermann IBM Linux Technology Center