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 EFCBFC433B4 for ; Tue, 11 May 2021 14:21:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BF6386187E for ; Tue, 11 May 2021 14:21:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231644AbhEKOWh convert rfc822-to-8bit (ORCPT ); Tue, 11 May 2021 10:22:37 -0400 Received: from frasgout.his.huawei.com ([185.176.79.56]:3061 "EHLO frasgout.his.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231154AbhEKOWg (ORCPT ); Tue, 11 May 2021 10:22:36 -0400 Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FffvS4G8Sz6wkkD; Tue, 11 May 2021 22:10:12 +0800 (CST) Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 11 May 2021 16:21:28 +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; Tue, 11 May 2021 16:21:28 +0200 From: Roberto Sassu To: Mimi Zohar , "mjg59@google.com" CC: "linux-integrity@vger.kernel.org" , "linux-security-module@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Christian Brauner , Andreas Gruenbacher , kernel test robot Subject: RE: [PATCH v6 08/11] evm: Allow setxattr() and setattr() for unmodified metadata Thread-Topic: [PATCH v6 08/11] evm: Allow setxattr() and setattr() for unmodified metadata Thread-Index: AQHXQaKHvFPvOA7oV0m5qAvk17yFuareOl6AgAAjMeA= Date: Tue, 11 May 2021 14:21:28 +0000 Message-ID: References: <20210505112935.1410679-1-roberto.sassu@huawei.com> <20210505113329.1410943-4-roberto.sassu@huawei.com> <735bae46f0772b40ef6ecfb3c6fe0267b3ebbee8.camel@linux.ibm.com> In-Reply-To: <735bae46f0772b40ef6ecfb3c6fe0267b3ebbee8.camel@linux.ibm.com> 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: > From: Mimi Zohar [mailto:zohar@linux.ibm.com] > Sent: Tuesday, May 11, 2021 4:12 PM > Hi Roberto, > > On Wed, 2021-05-05 at 13:33 +0200, Roberto Sassu wrote: > > With the patch to allow xattr/attr operations if a portable signature > > verification fails, cp and tar can copy all xattrs/attrs so that at the > > end of the process verification succeeds. > > > > However, it might happen that the xattrs/attrs are already set to the > > correct value (taken at signing time) and signature verification succeeds > > before the copy has completed. For example, an archive might contains files > > owned by root and the archive is extracted by root. > > > > Then, since portable signatures are immutable, all subsequent operations > > fail (e.g. fchown()), even if the operation is legitimate (does not alter > > the current value). > > > > This patch avoids this problem by reporting successful operation to user > > space when that operation does not alter the current value of xattrs/attrs. > > I must be missing something. If both the IMA and EVM status flags are > reset after xattr or attr modification, do we really need to prevent > any metadata - same or different - changes? Both evm_protect_xattr() > and evm_inode_setattr() would need to be modified to allow > INTEGRITY_PASS_IMMUTABLE. Hi Mimi yes, given that the IMA and EVM flags are reset, it should not be a problem to allow changes. However, I think it is useful to keep the current behavior. For example, it would prevent an accidental change of the SELinux label during the relabeling process. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Li Jian, Shi Yanli > thanks, > > Mimi