From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3986C48BE6 for ; Fri, 11 Jun 2021 09:44:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CA267613D5 for ; Fri, 11 Jun 2021 09:44:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230514AbhFKJqF convert rfc822-to-8bit (ORCPT ); Fri, 11 Jun 2021 05:46:05 -0400 Received: from frasgout.his.huawei.com ([185.176.79.56]:3206 "EHLO frasgout.his.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230356AbhFKJqD (ORCPT ); Fri, 11 Jun 2021 05:46:03 -0400 Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4G1bKC0QxMz6L777; Fri, 11 Jun 2021 17:34:39 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) 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; Fri, 11 Jun 2021 11:44:03 +0200 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2176.012; Fri, 11 Jun 2021 11:44:03 +0200 From: Roberto Sassu To: "viro@zeniv.linux.org.uk" , Mimi Zohar , "paul@paul-moore.com" , "Stephen Smalley" , "casey@schaufler-ca.com" , Stefan Berger CC: "linux-integrity@vger.kernel.org" , "linux-security-module@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "selinux@vger.kernel.org" Subject: Size mismatch between vfs_getxattr_alloc() and vfs_getxattr() Thread-Topic: Size mismatch between vfs_getxattr_alloc() and vfs_getxattr() Thread-Index: AddepfVXRzZV65zDQYWfY30E1Ui8ng== Date: Fri, 11 Jun 2021 09:44:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.98.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello the ima-evm-utils tool discovered an issue doing signature verification of xattrs. On kernel side, EVM reads the xattr value with vfs_getxattr_alloc(), which gets the value directly from the xattr handler. On user side, ima-evm-utils reads the value with the lgetxattr() system call, which gets the value from LSMs. There is a corner case, where security.selinux is set directly with setfattr without adding \0 at the end. In this case, the kernel and the user see different values due to the fact that the former gets the raw value from the xattr handler, and the latter gets the value normalized by SELinux (which adds \0). I found that originally also lgetxattr() was getting the value from the xattr handler. This changed with: commit 4bea58053f206be9a89ca35850f9ad295dac2042 Author: David P. Quigley Date: Mon Feb 4 22:29:40 2008 -0800 VFS: Reorder vfs_getxattr to avoid unnecessary calls to the LSM which directly calls LSMs for security.* xattrs. Given that this patch is there for a long time, I would ask if it makes sense to fix this issue. The way I would do it is to check if the size returned by the xattr handler is the same of the size returned by LSMs. If not, I would get the value from the xattr handler. Although this change does not check the xattr content, it is sufficient to fix the issue. Any opinion? Thanks Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Li Jian, Shi Yanli