From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:34001 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751500AbdHPLFp (ORCPT ); Wed, 16 Aug 2017 07:05:45 -0400 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7GB3lUY054726 for ; Wed, 16 Aug 2017 07:05:44 -0400 Received: from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145]) by mx0a-001b2d01.pphosted.com with ESMTP id 2ccm223ajh-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 16 Aug 2017 07:05:44 -0400 Received: from localhost by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 16 Aug 2017 21:05:42 +1000 Subject: Re: [PATCH v6 0/6] define new fs integrity_read method From: Mimi Zohar To: James Morris , Christoph Hellwig Cc: Al Viro , Matthew Garrett , linux-fsdevel@vger.kernel.org, linux-ima-devel@lists.sourceforge.net, linux-security-module@vger.kernel.org Date: Wed, 16 Aug 2017 07:05:35 -0400 In-Reply-To: References: <1502808237-2035-1-git-send-email-zohar@linux.vnet.ibm.com> <20170816063410.GB16531@lst.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <1502881535.5275.27.camel@linux.vnet.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, 2017-08-16 at 19:52 +1000, James Morris wrote: > On Wed, 16 Aug 2017, Christoph Hellwig wrote: > > > On Wed, Aug 16, 2017 at 12:43:58PM +1000, James Morris wrote: > > > On Tue, 15 Aug 2017, Mimi Zohar wrote: > > > > > > > To resolve this locking problem, this patch set introduces a new > > > > ->integrity_read file operation method. Until all filesystems > > > > define the new ->integrity_read method, files that were previously > > > > measured might not be currently measured and files that were > > > > previously appraised might fail to be appraised properly. > > > > > > Are there any such filesystems in mainline which are not getting an > > > integrity_read method in this patchset? > > > > There are a few, mostly because we're pretty sure the previous integrity > > code did the wrong thing for them - e.g. ocfs2 and gfs2 where locking > > vs operations on other cluster nodes was missing, or NFS where in addition > > to the above deadlocks were 100% reprodicible with current code. > > Should we do a warn_once for these filesystems when IMA is used? I don't think it is necessary.  In terms of IMA-measurement, any file in policy on an unsupported filesystem will be in the measurement list, but the file hash will be 0's.  In terms of IMA-appraisal, any file in policy on an unsupported filesystem will fail appraisal, since the file hash is 0. A separate patch set will emit a warning when a file system is mounted without i_version. Mimi From mboxrd@z Thu Jan 1 00:00:00 1970 From: zohar@linux.vnet.ibm.com (Mimi Zohar) Date: Wed, 16 Aug 2017 07:05:35 -0400 Subject: [PATCH v6 0/6] define new fs integrity_read method In-Reply-To: References: <1502808237-2035-1-git-send-email-zohar@linux.vnet.ibm.com> <20170816063410.GB16531@lst.de> Message-ID: <1502881535.5275.27.camel@linux.vnet.ibm.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Wed, 2017-08-16 at 19:52 +1000, James Morris wrote: > On Wed, 16 Aug 2017, Christoph Hellwig wrote: > > > On Wed, Aug 16, 2017 at 12:43:58PM +1000, James Morris wrote: > > > On Tue, 15 Aug 2017, Mimi Zohar wrote: > > > > > > > To resolve this locking problem, this patch set introduces a new > > > > ->integrity_read file operation method. Until all filesystems > > > > define the new ->integrity_read method, files that were previously > > > > measured might not be currently measured and files that were > > > > previously appraised might fail to be appraised properly. > > > > > > Are there any such filesystems in mainline which are not getting an > > > integrity_read method in this patchset? > > > > There are a few, mostly because we're pretty sure the previous integrity > > code did the wrong thing for them - e.g. ocfs2 and gfs2 where locking > > vs operations on other cluster nodes was missing, or NFS where in addition > > to the above deadlocks were 100% reprodicible with current code. > > Should we do a warn_once for these filesystems when IMA is used? I don't think it is necessary. ?In terms of IMA-measurement, any file in policy on an unsupported filesystem will be in the measurement list, but the file hash will be 0's. ?In terms of IMA-appraisal, any file in policy on an unsupported filesystem will fail appraisal, since the file hash is 0. A separate patch set will emit a warning when a file system is mounted without i_version. Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html