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.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 C4FF5C31E4A for ; Thu, 13 Jun 2019 15:55:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A4E7720851 for ; Thu, 13 Jun 2019 15:55:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732024AbfFMPzb (ORCPT ); Thu, 13 Jun 2019 11:55:31 -0400 Received: from lhrrgout.huawei.com ([185.176.76.210]:33007 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731543AbfFMIv6 (ORCPT ); Thu, 13 Jun 2019 04:51:58 -0400 Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E13342F4C597DB972D83; Thu, 13 Jun 2019 09:51:56 +0100 (IST) Received: from [10.220.96.108] (10.220.96.108) by smtpsuk.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 13 Jun 2019 09:51:50 +0100 Subject: Re: [PATCH v3 0/2] ima/evm fixes for v5.2 To: Janne Karhunen CC: Mimi Zohar , , , , , References: <20190606112620.26488-1-roberto.sassu@huawei.com> <144bf319-ea0c-f6b6-5737-0aac34f37186@huawei.com> <3911846b-f836-592a-81e1-a2fd25470d98@huawei.com> From: Roberto Sassu Message-ID: Date: Thu, 13 Jun 2019 10:51:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.220.96.108] X-CFilter-Loop: Reflected Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On 6/13/2019 10:04 AM, Janne Karhunen wrote: > On Thu, Jun 13, 2019 at 10:50 AM Roberto Sassu wrote: > >>> Would the appraise actually need any changes, just keep the >>> IMA_NEW_FILE in ima_check_last_writer()? Of course it's not that easy >>> (it never is) as the iint could go away and things like that, but with >>> some tweaks? >> >> I think the problem would be that the code that sets the status to >> INTEGRITY_PASS is not executed, because the file gets security.ima after >> the first write. > > We have a patchset coming shortly that starts tracking the inode > changes as we go, so first time we fix it is when the file is created > before it has any content (!); > > diff --git a/security/integrity/ima/ima_appraise.c > b/security/integrity/ima/ima_appraise.c > index 5fb7127bbe68..da4f0afe0348 100644 > --- a/security/integrity/ima/ima_appraise.c > +++ b/security/integrity/ima/ima_appraise.c > @@ -236,8 +236,10 @@ int ima_appraise_measurement(enum ima_hooks func, > iint->flags |= IMA_NEW_FILE; > if ((iint->flags & IMA_NEW_FILE) && > (!(iint->flags & IMA_DIGSIG_REQUIRED) || > - (inode->i_size == 0))) > + (inode->i_size == 0))) { > + ima_fix_xattr(dentry, iint); > status = INTEGRITY_PASS; Some time ago I developed this patch: http://kernsec.org/pipermail/linux-security-module-archive/2017-November/004569.html Since the appraisal flags are not cleared, ima_appraise_measurement() is not executed again and the problem with EVM does not arise. Roberto -- HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Bo PENG, Jian LI, Yanli SHI