From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:41320 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752767AbeCOUdx (ORCPT ); Thu, 15 Mar 2018 16:33:53 -0400 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2FKTiWD085833 for ; Thu, 15 Mar 2018 16:33:53 -0400 Received: from e18.ny.us.ibm.com (e18.ny.us.ibm.com [129.33.205.208]) by mx0b-001b2d01.pphosted.com with ESMTP id 2gqyeh9md7-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Thu, 15 Mar 2018 16:33:53 -0400 Received: from localhost by e18.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 15 Mar 2018 16:33:52 -0400 References: <20180314202020.3794-1-bauerman@linux.vnet.ibm.com> <20180314202020.3794-4-bauerman@linux.vnet.ibm.com> <20180314214045.GC14289@mail.hallyn.com> <87efkmjjc7.fsf@morokweng.localdomain> <1521141514.3547.637.camel@linux.vnet.ibm.com> From: Thiago Jung Bauermann To: Mimi Zohar Cc: "Serge E. Hallyn" , linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, James Morris , Dmitry Kasatkin Subject: Re: [PATCH 3/4] ima: Improvements in ima_appraise_measurement() In-reply-to: <1521141514.3547.637.camel@linux.vnet.ibm.com> Date: Thu, 15 Mar 2018 17:33:42 -0300 MIME-Version: 1.0 Content-Type: text/plain Message-Id: <874llhoz89.fsf@morokweng.localdomain> Sender: linux-integrity-owner@vger.kernel.org List-ID: Mimi Zohar writes: > On Wed, 2018-03-14 at 21:03 -0300, Thiago Jung Bauermann wrote: >> Hello Serge, >> >> Thanks for quickly reviewing these patches! >> >> Serge E. Hallyn writes: >> >> > Quoting Thiago Jung Bauermann (bauerman@linux.vnet.ibm.com): >> >> From: Mimi Zohar >> >> @@ -241,16 +241,20 @@ int ima_appraise_measurement(enum ima_hooks func, >> >> } >> >> >> >> status = evm_verifyxattr(dentry, XATTR_NAME_IMA, xattr_value, rc, iint); >> >> - if ((status != INTEGRITY_PASS) && >> >> - (status != INTEGRITY_PASS_IMMUTABLE) && >> >> - (status != INTEGRITY_UNKNOWN)) { >> >> - if ((status == INTEGRITY_NOLABEL) >> >> - || (status == INTEGRITY_NOXATTRS)) >> >> - cause = "missing-HMAC"; >> >> - else if (status == INTEGRITY_FAIL) >> >> - cause = "invalid-HMAC"; >> >> + switch (status) { >> >> + case INTEGRITY_PASS: >> >> + case INTEGRITY_PASS_IMMUTABLE: >> >> + case INTEGRITY_UNKNOWN: >> > >> > Wouldn't it be more future-proof to replace this with a 'default', or >> > to at least add a "default: BUG()" to catch new status values? >> >> I agree. I like the "default: BUG()" option. > > Agreed. I would put it at the end after INTEGRITY_FAIL. Ok, what about the version below? >> >> >> + break; >> >> + case INTEGRITY_NOXATTRS: /* No EVM protected xattrs. */ >> >> + case INTEGRITY_NOLABEL: /* No security.evm xattr. */ >> >> + cause = "missing-HMAC"; >> >> + goto out; >> >> + case INTEGRITY_FAIL: /* Invalid HMAC/signature. */ >> >> + cause = "invalid-HMAC"; >> >> goto out; >> >> } >> >> + >> >> switch (xattr_value->type) { >> >> case IMA_XATTR_DIGEST_NG: >> >> /* first byte contains algorithm id */ >> >> @@ -316,17 +320,20 @@ int ima_appraise_measurement(enum ima_hooks func, >> >> integrity_audit_msg(AUDIT_INTEGRITY_DATA, inode, filename, >> >> op, cause, rc, 0); >> >> } else if (status != INTEGRITY_PASS) { >> >> + /* Fix mode, but don't replace file signatures. */ >> >> if ((ima_appraise & IMA_APPRAISE_FIX) && >> >> (!xattr_value || >> >> xattr_value->type != EVM_IMA_XATTR_DIGSIG)) { >> >> if (!ima_fix_xattr(dentry, iint)) >> >> status = INTEGRITY_PASS; >> >> - } else if ((inode->i_size == 0) && >> >> - (iint->flags & IMA_NEW_FILE) && >> >> - (xattr_value && >> >> - xattr_value->type == EVM_IMA_XATTR_DIGSIG)) { >> >> + } >> >> + >> >> + /* Permit new files with file signatures, but without data. */ >> >> + if (inode->i_size == 0 && iint->flags & IMA_NEW_FILE && >> > >> > This may be correct, but it's not identical to what you're replacing. >> > Since in either case you're setting status to INTEGRITY_PASS the final >> > result is the same, but with a few extra possible steps. Not sure >> > whether that matters. >> >> Good point. I'll have to defer this one to Mimi though. > > The end result is the same, but add some needed comments. The patch is unchanged here, then. -- Thiago Jung Bauermann IBM Linux Technology Center