Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3733781pxj; Mon, 21 Jun 2021 05:30:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzM29LpjPVQ5ki1Zuv70Vyq0/mwfvBUuih3kHANqRWRpd1NYGVz9049DOzJsf3tbtMuS4j9 X-Received: by 2002:a5d:8190:: with SMTP id u16mr20024352ion.158.1624278622310; Mon, 21 Jun 2021 05:30:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624278622; cv=none; d=google.com; s=arc-20160816; b=fEXCFNGxncDKVKKHebonkANCGWi5vFSv9UPNBwdJmFiNaWu2GGpaEybfnKSWKX+VwK uQTsqwQK7/Dis9nUJWP/4ZRh0O7cU8qO5jaY3K5QJVn9SZSSyO/Qrlv5ZCBooV+s0GRX MAl8b9nfTBMj1wexF2HdZLsT1SWmrLDB8MF8jWZZZAWXfyPQot+2eiJLft3IAjh9DKSh VeyOac3NA8O92KeAOfqAmwirYWFx0L4cJj1WKlodgmPl9m8m5O2GA9zIvHaM+aSD69jv OXFaVAO5xIGtkaOOKBTflesj7bSYNvuVO8DsOmAmobQEvkoB3GsEmQ+hC2vH8XEwta61 G5QA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=xiYBrG95nPTyO/eNniVWuNPhhW6/LRHWkGZBWBUQX+o=; b=ArEnqctOzUSy45nT7KxP6ijdDjRRZMmC993n2vFkYsEtIznRTEabK7htzu1xzmYnP6 qZlL1l5uLk8f6uXQj03yRQVoRTwelGv36OOj5EzZ2AdY3fPipVKWSn4xPSg4mM7e6tpe MlFZZJ2noJ3rMug3O661FgSooAEKAxb5eqHvChRMmu8lfZ07hT9vj3b8ALYvzd280UPk CQUoIYAAE+kK+woNa+r9r7zDLE8CqC5u6S1wxONsRUByLvF+ag3K1xNAnG1sHJnqxJAO OqBsILn8E/ndLsxlbLxJZJ01uBgnH88+CloyKrSOLU0w2XRP3GxdeC23DQupenNnSIxX tmrw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d20si10811579ilu.128.2021.06.21.05.30.09; Mon, 21 Jun 2021 05:30:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229888AbhFUMbs (ORCPT + 99 others); Mon, 21 Jun 2021 08:31:48 -0400 Received: from frasgout.his.huawei.com ([185.176.79.56]:3295 "EHLO frasgout.his.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229695AbhFUMbq (ORCPT ); Mon, 21 Jun 2021 08:31:46 -0400 Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4G7pQw6HZLz6H8DN; Mon, 21 Jun 2021 20:16:08 +0800 (CST) Received: from roberto-ThinkStation-P620.huawei.com (10.204.62.217) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 21 Jun 2021 14:29:29 +0200 From: Roberto Sassu To: , , , , CC: , , , , Roberto Sassu Subject: [PATCH v2] evm: Check xattr size discrepancy between kernel and user Date: Mon, 21 Jun 2021 14:29:12 +0200 Message-ID: <20210621122912.1472470-1-roberto.sassu@huawei.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.204.62.217] X-ClientProxiedBy: lhreml752-chm.china.huawei.com (10.201.108.202) To fraeml714-chm.china.huawei.com (10.206.15.33) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The kernel and the user obtain an xattr value in two different ways: kernel (EVM): uses vfs_getxattr_alloc() which obtains the xattr value from the filesystem handler (raw value); user (ima-evm-utils): uses vfs_getxattr() which obtains the xattr value from the LSMs (normalized value). Normally, this does not have an impact unless security.selinux is set with setfattr, with a value not terminated by '\0' (this is not the recommended way, security.selinux should be set with the appropriate tools such as chcon and restorecon). In this case, the kernel and the user see two different xattr values: the former sees the xattr value without '\0' (raw value), the latter sees the value with '\0' (value normalized by SELinux). This could result in two different verification outcomes from EVM and ima-evm-utils, if a signature was calculated with a security.selinux value terminated by '\0' and the value set in the filesystem is not terminated by '\0'. The former would report verification failure due to the missing '\0', while the latter would report verification success (because it gets the normalized value with '\0'). This patch mitigates this issue by comparing in evm_calc_hmac_or_hash() the size of the xattr returned by the two xattr functions and by warning the user if there is a discrepancy. Signed-off-by: Roberto Sassu Suggested-by: Mimi Zohar --- security/integrity/evm/evm_crypto.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c index 96b22f2ac27a..462c5258322a 100644 --- a/security/integrity/evm/evm_crypto.c +++ b/security/integrity/evm/evm_crypto.c @@ -221,7 +221,7 @@ static int evm_calc_hmac_or_hash(struct dentry *dentry, size_t xattr_size = 0; char *xattr_value = NULL; int error; - int size; + int size, user_space_size; bool ima_present = false; if (!(inode->i_opflags & IOP_XATTR) || @@ -276,6 +276,12 @@ static int evm_calc_hmac_or_hash(struct dentry *dentry, if (size < 0) continue; + user_space_size = vfs_getxattr(&init_user_ns, dentry, + xattr->name, NULL, 0); + if (user_space_size != size) + pr_debug("file %s: xattr %s size mismatch (kernel: %d, user: %d)\n", + dentry->d_name.name, xattr->name, size, + user_space_size); error = 0; xattr_size = size; crypto_shash_update(desc, (const u8 *)xattr_value, xattr_size); -- 2.25.1