From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:58714 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726612AbeJHSgf (ORCPT ); Mon, 8 Oct 2018 14:36:35 -0400 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w98BJNnO063520 for ; Mon, 8 Oct 2018 07:25:19 -0400 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0a-001b2d01.pphosted.com with ESMTP id 2n05ws1b4j-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 08 Oct 2018 07:25:18 -0400 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 8 Oct 2018 12:25:16 +0100 Subject: Re: Allow FUSE filesystems to provide out-of-band hashes to IMA From: Mimi Zohar To: Matthew Garrett Cc: linux-integrity , Dmitry Kasatkin , miklos@szeredi.hu, linux-fsdevel@vger.kernel.org, Alexander Viro Date: Mon, 08 Oct 2018 07:25:00 -0400 In-Reply-To: References: <20181004203007.217320-1-mjg59@google.com> <1538736566.3702.436.camel@linux.ibm.com> <1538763521.3541.31.camel@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <1538997900.15382.90.camel@linux.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, 2018-10-05 at 12:25 -0700, Matthew Garrett wrote: > On Fri, Oct 5, 2018 at 11:18 AM Mimi Zohar wrote: > > Right, the correct behavior should be not to trust FUSE filesystems, > > but since we don't break userspace there is the > > "ima_policy=fail_securely" boot command line option. > > There seem to be two scenarios: > > 1) You trust FUSE mounts, perhaps because you have some other policy > in place to ensure that only trusted binaries can mount stuff. In this > scenario you already trust that the filesystem will give you > consistent results when you read data from it - In the trusted mount scenario, we trust the data should not change between calculating the file hash and reading the file data, making it similar to other local filesystems.  Unlike other local filesystems, however, we can't detect when the file changes.  For this reason we need to re-calculate the file hash to measure/appraise the file each time. > it seems reasonable to > also trust it to give you back an accurate hash if you ask for one. Going from trusting the filesystem to behave properly, to trusting the file hash that the filesystem provides is a major leap.  We don't do this today for any local filesystem. > 2) You don't trust FUSE mounts, in which case you pass > ima_policy=fail_securely. This patch doesn't change that behaviour. > > I agree that using FUSE in general is incompatible with IMA's goals, > but it's possible to configure systems where you can ensure that only > trustworthy code is involved. In that scenario this patch improves > performance without compromising security. If you trust a FUSE filesystem to not only behave properly, but also to return file hashes, what is the value of measuring/appraising the files?  Define a custom policy that doesn't measure/appraise files on FUSE filesystems. Mimi