From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:60640 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751591AbeA2N6T (ORCPT ); Mon, 29 Jan 2018 08:58:19 -0500 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 w0TDs7cb020443 for ; Mon, 29 Jan 2018 08:58:18 -0500 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0a-001b2d01.pphosted.com with ESMTP id 2ft4rtrjm1-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 29 Jan 2018 08:58:18 -0500 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 29 Jan 2018 13:58:15 -0000 Subject: Re: [Lsf-pc] [LSF/MM TOPIC] fs-verity: file system-level integrity protection From: Mimi Zohar To: "Theodore Ts'o" Cc: James Bottomley , Andreas Dilger , linux-fsdevel , lsf-pc@lists.linux-foundation.org Date: Mon, 29 Jan 2018 08:58:11 -0500 In-Reply-To: <1517227741.29187.515.camel@linux.vnet.ibm.com> References: <275E5E86-635E-4D79-9AC9-3D24318EDDDF@dilger.ca> <1517069959.3012.13.camel@HansenPartnership.com> <20180128024604.GA12320@thunk.org> <1517162590.3082.55.camel@HansenPartnership.com> <20180128214925.GA13621@thunk.org> <1517180692.29187.317.camel@linux.vnet.ibm.com> <20180129003842.GA29839@thunk.org> <1517190821.29187.415.camel@linux.vnet.ibm.com> <20180129023820.GA1565@thunk.org> <1517197150.29187.457.camel@linux.vnet.ibm.com> <20180129045012.GB9516@thunk.org> <1517227741.29187.515.camel@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <1517234291.29187.540.camel@linux.vnet.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, 2018-01-29 at 07:09 -0500, Mimi Zohar wrote: > Bringing it all together, what is needed? > - the signature of the Merkle tree hash > - a method for validating the signature > - a method for knowing if fs-verity is enabled on the system > A mode where fs-verity can not be disabled on the local, running > system, once enabled. > - lastly, a policy.  Just because a file has a signature, does not > necessarily imply that it should be verified. Before people start saying that the policy doesn't belong in IMA, maybe it doesn't, but let me describe a couple of use cases to illustrate the problems: - On systems that support multiple types of signatures, it's important to be able to define which signature types are acceptable, or for that matter if a file hash suffices (normally used for mutable files), on a per file basis. - Similarly, suppose the trusted keyring contains multiple keys.  I've installed software from multiple software providers and loaded their public keys on the trusted keyring.  Is using any key to verify the file signature acceptable?  How would you indicate which key is acceptable for which file. For embedded or closed systems, a single key can be used to sign all files, but for the generic case, like our laptops, this doesn't scale. Mimi