From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:54694 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751566AbeAZRyL (ORCPT ); Fri, 26 Jan 2018 12:54:11 -0500 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0QHr5bi031753 for ; Fri, 26 Jan 2018 12:54:11 -0500 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0b-001b2d01.pphosted.com with ESMTP id 2fr5cw1cmm-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 26 Jan 2018 12:54:10 -0500 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 26 Jan 2018 17:54:08 -0000 Subject: Re: [LSF/MM TOPIC] fs-verity: file system-level integrity protection From: Mimi Zohar To: "Theodore Ts'o" , lsf-pc@lists.linux-foundation.org Cc: linux-fsdevel , linux-integrity Date: Fri, 26 Jan 2018 12:54:03 -0500 In-Reply-To: <20180125191152.GA11197@thunk.org> References: <20180125191152.GA11197@thunk.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Message-Id: <1516989243.29187.54.camel@linux.vnet.ibm.com> Sender: linux-integrity-owner@vger.kernel.org List-ID: [Cc'ing the linux-integrity mailing list] On Thu, 2018-01-25 at 14:11 -0500, Theodore Ts'o wrote: > I'd like to talk about a proposal to implement and upstream something > that we've been calling fs-verity, which is something like dm-verity, > but implemnted on a per-file basis. It will be implemnted much like > fs/crypto, in that most of the code will be in a generic layer, with > minimal modifications needed in the file system layer. > > The merkle tree will be located after file's normal data, and then > after the package manager sets the verity bit, i_size will be updated > so that the fs-verity header and merkle tree will be "hidden" from > userspace and the file will become immutable. > > How does this differ from IMA's file integrity? > > *) The pages are verified as they are read, so pages are verified as > they are read the storage device; this avoids a large latency hit when > the file is first opened or referenced. Secure and trusted boot standards require files to be measured and appraised before usage. Perhaps verifying the merkle tree satifies these requirements. IMA-appraisal is being extended to support appended signatures, as generated by scripts/sign-file. This proposed method of calculating the file hash could be another signature method. > *) The design and code are done by file system developers, so it > doesn't have the locking problems of the IMA code. True, the locking problem is a direct result of using xattrs for storing file metadata, which requires taking the i_rwsem exclusively for writing. This solution circumvents the locking issues because it appends the file metadata to the file data instead of using xattrs. By using atomic flags, as suggested by Linus, Dmitry Kasatkin has resolved the xattr locking issue. The patch is currently staged to be upstreamed in the next open window. > > The initial use case of this will be for Android, where the latency > concerns of doing the full checksum at file open time is important. > > In the future, the fact that a file has been signed using fs-verity, > using a PKCS 11 signature with a key on a trusted keyring (possibly > the same one used for signed kernel modules, or perhaps a separate > keyring) could be used as input into a security policy which requires > this for say, setuid executables, setuid shell scripts, etc. > > Most of this feature could also be used with a non-cryptographic > checksum to provide data checksums for read-only files in a general > way for all file systems. It wouldn't be as flexible as btrfs, but > for files being stored for backup purposes, it should work quite well. Signing and verifying local file signatures, is a lot simpler than supporting a full software package life cycle. Can the file metadata - signatures and trees - be calculated and included in software packages, with the file data, for distribution? In terms of remote filesystems, the same trust issues exist with this solution as with IMA-appraisal. Mimi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:54688 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751398AbeAZRyL (ORCPT ); Fri, 26 Jan 2018 12:54:11 -0500 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0QHr3CK031600 for ; Fri, 26 Jan 2018 12:54:10 -0500 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0b-001b2d01.pphosted.com with ESMTP id 2fr5cw1cmj-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 26 Jan 2018 12:54:10 -0500 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 26 Jan 2018 17:54:08 -0000 Subject: Re: [LSF/MM TOPIC] fs-verity: file system-level integrity protection From: Mimi Zohar To: "Theodore Ts'o" , lsf-pc@lists.linux-foundation.org Cc: linux-fsdevel , linux-integrity Date: Fri, 26 Jan 2018 12:54:03 -0500 In-Reply-To: <20180125191152.GA11197@thunk.org> References: <20180125191152.GA11197@thunk.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <1516989243.29187.54.camel@linux.vnet.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: [Cc'ing the linux-integrity mailing list] On Thu, 2018-01-25 at 14:11 -0500, Theodore Ts'o wrote: > I'd like to talk about a proposal to implement and upstream something > that we've been calling fs-verity, which is something like dm-verity, > but implemnted on a per-file basis. It will be implemnted much like > fs/crypto, in that most of the code will be in a generic layer, with > minimal modifications needed in the file system layer. > > The merkle tree will be located after file's normal data, and then > after the package manager sets the verity bit, i_size will be updated > so that the fs-verity header and merkle tree will be "hidden" from > userspace and the file will become immutable. > > How does this differ from IMA's file integrity? > > *) The pages are verified as they are read, so pages are verified as > they are read the storage device; this avoids a large latency hit when > the file is first opened or referenced. Secure and trusted boot standards require files to be measured and appraised before usage.  Perhaps verifying the merkle tree satifies these requirements. IMA-appraisal is being extended to support appended signatures, as generated by scripts/sign-file.  This proposed method of calculating the file hash could be another signature method. > *) The design and code are done by file system developers, so it > doesn't have the locking problems of the IMA code. True, the locking problem is a direct result of using xattrs for storing file metadata, which requires taking the i_rwsem exclusively for writing.  This solution circumvents the locking issues because it appends the file metadata to the file data instead of using xattrs. By using atomic flags, as suggested by Linus, Dmitry Kasatkin has resolved the xattr locking issue.  The patch is currently staged to be upstreamed in the next open window. > > The initial use case of this will be for Android, where the latency > concerns of doing the full checksum at file open time is important. > > In the future, the fact that a file has been signed using fs-verity, > using a PKCS 11 signature with a key on a trusted keyring (possibly > the same one used for signed kernel modules, or perhaps a separate > keyring) could be used as input into a security policy which requires > this for say, setuid executables, setuid shell scripts, etc. > > Most of this feature could also be used with a non-cryptographic > checksum to provide data checksums for read-only files in a general > way for all file systems. It wouldn't be as flexible as btrfs, but > for files being stored for backup purposes, it should work quite well. Signing and verifying local file signatures, is a lot simpler than supporting a full software package life cycle.  Can the file metadata - signatures and trees - be calculated and included in software packages, with the file data, for distribution? In terms of remote filesystems, the same trust issues exist with this solution as with IMA-appraisal. Mimi