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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS 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 313AEC10F13 for ; Mon, 8 Apr 2019 13:11:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0A62B213F2 for ; Mon, 8 Apr 2019 13:11:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726530AbfDHNLG (ORCPT ); Mon, 8 Apr 2019 09:11:06 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:37024 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725933AbfDHNLG (ORCPT ); Mon, 8 Apr 2019 09:11:06 -0400 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x38D4jTA055211 for ; Mon, 8 Apr 2019 09:11:05 -0400 Received: from e06smtp02.uk.ibm.com (e06smtp02.uk.ibm.com [195.75.94.98]) by mx0a-001b2d01.pphosted.com with ESMTP id 2rr4jrfk97-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 08 Apr 2019 09:11:04 -0400 Received: from localhost by e06smtp02.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 8 Apr 2019 14:11:02 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp02.uk.ibm.com (192.168.101.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 8 Apr 2019 14:10:59 +0100 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x38DAxFc43778206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 8 Apr 2019 13:10:59 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D3C6F42045; Mon, 8 Apr 2019 13:10:58 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1457E4204F; Mon, 8 Apr 2019 13:10:58 +0000 (GMT) Received: from localhost.localdomain (unknown [9.80.94.212]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 8 Apr 2019 13:10:57 +0000 (GMT) Subject: Re: appraisal reset safety From: Mimi Zohar To: Janne Karhunen , Dmitry Kasatkin Cc: linux-integrity@vger.kernel.org Date: Mon, 08 Apr 2019 09:10:47 -0400 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 19040813-0008-0000-0000-000002D78660 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19040813-0009-0000-0000-00002243A232 Message-Id: <1554729047.17244.95.camel@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-08_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080110 Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On Mon, 2019-04-08 at 12:22 +0300, Janne Karhunen wrote: > Hi, > > Hmm, looks to me ima_update_xattr seems to be kicking in only from the > appraisal failure when in fix mode or via fput() delayed work item. > So, no sync() or anything like that will ever help and there is > nothing listening on the i_version updates. Moreover, there is no > integrity hook for write() or sync() to put such update in. Uh. I was > under impression it would somehow see the interim file updates, but I > guess no. Fundamental misunderstanding from my point of view how this > thing works, duh. The question of how much/how little to measure/appraise/audit is based on policy and affects the integrity of the system and its performance.  Detecting and updating the file hash each time the file changes would have major performance repercussions.  Even that wouldn't solve the problem, as the file change is in cache.  Writing the file hash as an xattr and making the file change persistent needs to be coordinated, probably at the filesystem level. Mimi