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=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 B839FC433DF for ; Mon, 10 Aug 2020 23:37:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 895F8206DA for ; Mon, 10 Aug 2020 23:37:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JlpYrwH8" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727781AbgHJXg7 (ORCPT ); Mon, 10 Aug 2020 19:36:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54912 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726859AbgHJXg6 (ORCPT ); Mon, 10 Aug 2020 19:36:58 -0400 Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8065CC06174A; Mon, 10 Aug 2020 16:36:53 -0700 (PDT) Received: by mail-il1-x141.google.com with SMTP id y18so9039393ilp.10; Mon, 10 Aug 2020 16:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LKyAC8SmzXgvrrYpq/s/3TsU/WRs+a9c0PUjRq1OPBQ=; b=JlpYrwH8LuYxS/kUo816+90tW0+/ylAfqYVP9WkSSIXWKS3+fXoIPBSsPTXz2V3n+V zfZjMbVssR/VpKiSgjUnAf/P3DOv2eNyNduLJeu4owJi5tGfGWS5Ew4ooZigMhEA5VxR 3maepQLkw6Gz7N+bsh46aLUgeLKvPqrQxXsZ/VInB84fAR/q3ofXK7vWEerCetXXYW0r BB+wUPLUssFy9WzQaaMgPg+DFTUtT6PrMdo+buwwPVDSbcB0TqzV0zsdl8KTpwJ9m4hf EwgGlp/joouyPXwhKZaHTR2Fekur8oaosXQK9E/BnvFHhfwtmh8JARTWM1TDRtQNrIJ5 0atA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LKyAC8SmzXgvrrYpq/s/3TsU/WRs+a9c0PUjRq1OPBQ=; b=cNwLScCUv+Q3pkO31O18CFnOVi8hKXXb1UXG0eZaQyNTXLIKL+9B1bUI18czvgcEEf OE3rrr1wQcGV/KNoTICMRX2ffSfLTlvg5Vak8ooFjQxcIZPHp9nbLYqx7FvtQq6cjf0c 0UWtmf26eQ0VdZYxbGj0gvSmvGNyG2OZh5PatmC1RtTITj5g+JTqJJGx2IjS85Lee1wO rnTWHBx5Lrvp2flg8C4IaYAb5BuwQI6q5fQunHUi16yU+EVB9MVFWEEFNlZfwI12unA/ FCk2Qp1f5vH+SL09Tv8nh/j61BbLaVDPlChWje3RdxxYJnmEznLyLWoGFuxPvYhKQdxY CfeQ== X-Gm-Message-State: AOAM533/KfXHfMAOc/wMFlSqUoevVSyXO+27lABqCtsMVcLEql/6VUbH UVH6OjGbAEUBIlvk8G0tYgo= X-Google-Smtp-Source: ABdhPJy1S3g3p98Xi9EcsXNS6CmJzbt5rxJnpB8itBPIozhsJmELv5fUbjHEUzglUQlam96oFkStKA== X-Received: by 2002:a92:8b11:: with SMTP id i17mr19417396ild.212.1597102610889; Mon, 10 Aug 2020 16:36:50 -0700 (PDT) Received: from anon-dhcp-152.1015granger.net (c-68-61-232-219.hsd1.mi.comcast.net. [68.61.232.219]) by smtp.gmail.com with ESMTPSA id o11sm11353713iom.25.2020.08.10.16.36.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2020 16:36:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE) From: Chuck Lever In-Reply-To: <1597073737.3966.12.camel@HansenPartnership.com> Date: Mon, 10 Aug 2020 19:36:47 -0400 Cc: Mimi Zohar , James Morris , Deven Bowers , Pavel Machek , Sasha Levin , snitzer@redhat.com, dm-devel@redhat.com, tyhicks@linux.microsoft.com, agk@redhat.com, Paul Moore , Jonathan Corbet , nramas@linux.microsoft.com, serge@hallyn.com, pasha.tatashin@soleen.com, Jann Horn , linux-block@vger.kernel.org, Al Viro , Jens Axboe , mdsakib@microsoft.com, open list , eparis@redhat.com, linux-security-module@vger.kernel.org, linux-audit@redhat.com, linux-fsdevel , linux-integrity@vger.kernel.org, jaskarankhurana@linux.microsoft.com Content-Transfer-Encoding: quoted-printable Message-Id: <6E907A22-02CC-42DD-B3CD-11D304F3A1A8@gmail.com> References: <20200728213614.586312-1-deven.desai@linux.microsoft.com> <20200802115545.GA1162@bug> <20200802140300.GA2975990@sasha-vm> <20200802143143.GB20261@amd> <1596386606.4087.20.camel@HansenPartnership.com> <1596639689.3457.17.camel@HansenPartnership.com> <329E8DBA-049E-4959-AFD4-9D118DEB176E@gmail.com> <1597073737.3966.12.camel@HansenPartnership.com> To: James Bottomley X-Mailer: Apple Mail (2.3608.80.23.2.2) Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org > On Aug 10, 2020, at 11:35 AM, James Bottomley = wrote: >=20 > On Sun, 2020-08-09 at 13:16 -0400, Mimi Zohar wrote: >> On Sat, 2020-08-08 at 13:47 -0400, Chuck Lever wrote: >>>> On Aug 5, 2020, at 2:15 PM, Mimi Zohar >>>> wrote: >>=20 >> >>=20 >>>> If block layer integrity was enough, there wouldn't have been a >>>> need for fs-verity. Even fs-verity is limited to read only >>>> filesystems, which makes validating file integrity so much >>>> easier. =46rom the beginning, we've said that fs-verity signatures >>>> should be included in the measurement list. (I thought someone >>>> signed on to add that support to IMA, but have not yet seen >>>> anything.) >>>=20 >>> Mimi, when you and I discussed this during LSS NA 2019, I didn't >>> fully understand that you expected me to implement signed Merkle >>> trees for all filesystems. At the time, it sounded to me like you >>> wanted signed Merkle trees only for NFS files. Is that still the >>> case? >>=20 >> I definitely do not expect you to support signed Merkle trees for all >> filesystems. My interested is from an IMA perspective of measuring >> and verifying the fs-verity Merkle tree root (and header info) >> signature. This is independent of which filesystems support it. >>=20 >>>=20 >>> The first priority (for me, anyway) therefore is getting the >>> ability to move IMA metadata between NFS clients and servers >>> shoveled into the NFS protocol, but that's been blocked for various >>> legal reasons. >>=20 >> Up to now, verifying remote filesystem file integrity has been out of >> scope for IMA. With fs-verity file signatures I can at least grasp >> how remote file integrity could possibly work. I don't understand >> how remote file integrity with existing IMA formats could be >> supported. You might want to consider writing a whitepaper, which >> could later be used as the basis for a patch set cover letter. >=20 > I think, before this, we can help with the basics (and perhaps we > should sort them out before we start documenting what we'll do). Thanks for the help! I just want to emphasize that documentation (eg, a specification) will be critical for remote filesystems. If any of this is to be supported by a remote filesystem, then we need an unencumbered description of the new metadata format rather than code. GPL-encumbered formats cannot be contributed to the NFS standard, and are probably difficult for other filesystems that are not Linux-native, like SMB, as well. > The > first basic is that a merkle tree allows unit at a time verification.=20= > First of all we should agree on the unit. Since we always fault a = page > at a time, I think our merkle tree unit should be a page not a block. Remote filesystems will need to agree that the size of that unit is the same everywhere, or the unit size could be stored in the per-file metadata. > Next, we should agree where the check gates for the per page accesses > should be ... definitely somewhere in readpage, I suspect and finally > we should agree how the merkle tree is presented at the gate. I think > there are three ways: >=20 > 1. Ahead of time transfer: The merkle tree is transferred and = verified > at some time before the accesses begin, so we already have a > verified copy and can compare against the lower leaf. > 2. Async transfer: We provide an async mechanism to transfer the > necessary components, so when presented with a unit, we check the > log n components required to get to the root > 3. The protocol actually provides the capability of 2 (like the SCSI > DIF/DIX), so to IMA all the pieces get presented instead of IMA > having to manage the tree A Merkle tree is potentially large enough that it cannot be stored in an extended attribute. In addition, an extended attribute is not a byte stream that you can seek into or read small parts of, it is retrieved in a single shot. For this reason, the idea was to save only the signature of the tree's root on durable storage. The client would retrieve that signature possibly at open time, and reconstruct the tree at that time. Or the tree could be partially constructed on-demand at the time each unit is to be checked (say, as part of 2. above). The client would have to reconstruct that tree again if memory pressure caused some or all of the tree to be evicted, so perhaps an on-demand mechanism is preferable. > There are also a load of minor things like how we get the head hash, > which must be presented and verified ahead of time for each of the > above 3. Also, changes to a file's content and its tree signature are not atomic. If a file is mutable, then there is the period between when the file content has changed and when the signature is updated. Some discussion of how a client is to behave in those situations will be necessary. -- Chuck Lever chucklever@gmail.com 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=-4.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 01706C433DF for ; Tue, 11 Aug 2020 01:38:22 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9DCEA20734 for ; Tue, 11 Aug 2020 01:38:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9DCEA20734 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-audit-bounces@redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-348-zLyu1o-mN-CD_8xmrZuu4A-1; Mon, 10 Aug 2020 21:38:18 -0400 X-MC-Unique: zLyu1o-mN-CD_8xmrZuu4A-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9D1D18015CE; Tue, 11 Aug 2020 01:38:12 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C161019C58; Tue, 11 Aug 2020 01:38:11 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id ED6111809557; Tue, 11 Aug 2020 01:38:05 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 07ANaucm006368 for ; Mon, 10 Aug 2020 19:36:56 -0400 Received: by smtp.corp.redhat.com (Postfix) id 722F5208DD81; Mon, 10 Aug 2020 23:36:56 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast06.extmail.prod.ext.rdu2.redhat.com [10.11.55.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6CC0B208DD83 for ; Mon, 10 Aug 2020 23:36:54 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 51371185A797 for ; Mon, 10 Aug 2020 23:36:54 +0000 (UTC) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-310-DLQsbmfCMPK42LQIPrIRag-1; Mon, 10 Aug 2020 19:36:52 -0400 X-MC-Unique: DLQsbmfCMPK42LQIPrIRag-1 Received: by mail-il1-f195.google.com with SMTP id z3so9092481ilh.3; Mon, 10 Aug 2020 16:36:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LKyAC8SmzXgvrrYpq/s/3TsU/WRs+a9c0PUjRq1OPBQ=; b=Oirn23L0HcX58OP/n5CYX+y3VstMrTh6qO+tmi8BFrcbDGuK3PATz9RVjerufZ+dWP ZS5twNNP5s5kAcfpzlq4iLoaop/TzM6OX0VkFHXW7bwJHpApzROA1eI5jjl/v+N9/0zm QhslfoaLovMHKgQmkA5QuVZCqhjO3orfn8LniTejrP058xKzxabS6pm0MMOyXTUvit21 xPYeEpkddTomxPJu+HTm9HWOX/PW7KxAfsh+irP7xSTCXYdH5BOhhbCCd+ZRk/pe8jhI uap1xAewDWna+P5kQPyUwKtEzAatMVJcpeyP/MVM1BzztW1i88yEQudzm1HqgvBvyVYV CW7g== X-Gm-Message-State: AOAM533AngZEeaj5Fc0i31EVA7Uy7BETtEKliEsf7d9PrYbwiiEl0W0h VqTqsiaXaJKBWNTlHRRjZvw= X-Google-Smtp-Source: ABdhPJy1S3g3p98Xi9EcsXNS6CmJzbt5rxJnpB8itBPIozhsJmELv5fUbjHEUzglUQlam96oFkStKA== X-Received: by 2002:a92:8b11:: with SMTP id i17mr19417396ild.212.1597102610889; Mon, 10 Aug 2020 16:36:50 -0700 (PDT) Received: from anon-dhcp-152.1015granger.net (c-68-61-232-219.hsd1.mi.comcast.net. [68.61.232.219]) by smtp.gmail.com with ESMTPSA id o11sm11353713iom.25.2020.08.10.16.36.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2020 16:36:49 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE) From: Chuck Lever In-Reply-To: <1597073737.3966.12.camel@HansenPartnership.com> Date: Mon, 10 Aug 2020 19:36:47 -0400 Message-Id: <6E907A22-02CC-42DD-B3CD-11D304F3A1A8@gmail.com> References: <20200728213614.586312-1-deven.desai@linux.microsoft.com> <20200802115545.GA1162@bug> <20200802140300.GA2975990@sasha-vm> <20200802143143.GB20261@amd> <1596386606.4087.20.camel@HansenPartnership.com> <1596639689.3457.17.camel@HansenPartnership.com> <329E8DBA-049E-4959-AFD4-9D118DEB176E@gmail.com> <1597073737.3966.12.camel@HansenPartnership.com> To: James Bottomley X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false; X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-MIME-Autoconverted: from quoted-printable to 8bit by lists01.pubmisc.prod.ext.phx2.redhat.com id 07ANaucm006368 X-loop: linux-audit@redhat.com X-Mailman-Approved-At: Mon, 10 Aug 2020 21:38:04 -0400 Cc: snitzer@redhat.com, Deven Bowers , Mimi Zohar , dm-devel@redhat.com, tyhicks@linux.microsoft.com, Pavel Machek , agk@redhat.com, Sasha Levin , Jonathan Corbet , James Morris , nramas@linux.microsoft.com, serge@hallyn.com, pasha.tatashin@soleen.com, Jann Horn , linux-block@vger.kernel.org, Al Viro , Jens Axboe , mdsakib@microsoft.com, open list , linux-security-module@vger.kernel.org, linux-audit@redhat.com, linux-fsdevel , linux-integrity@vger.kernel.org, jaskarankhurana@linux.microsoft.com X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=linux-audit-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > On Aug 10, 2020, at 11:35 AM, James Bottomley wrote: > > On Sun, 2020-08-09 at 13:16 -0400, Mimi Zohar wrote: >> On Sat, 2020-08-08 at 13:47 -0400, Chuck Lever wrote: >>>> On Aug 5, 2020, at 2:15 PM, Mimi Zohar >>>> wrote: >> >> >> >>>> If block layer integrity was enough, there wouldn't have been a >>>> need for fs-verity. Even fs-verity is limited to read only >>>> filesystems, which makes validating file integrity so much >>>> easier. From the beginning, we've said that fs-verity signatures >>>> should be included in the measurement list. (I thought someone >>>> signed on to add that support to IMA, but have not yet seen >>>> anything.) >>> >>> Mimi, when you and I discussed this during LSS NA 2019, I didn't >>> fully understand that you expected me to implement signed Merkle >>> trees for all filesystems. At the time, it sounded to me like you >>> wanted signed Merkle trees only for NFS files. Is that still the >>> case? >> >> I definitely do not expect you to support signed Merkle trees for all >> filesystems. My interested is from an IMA perspective of measuring >> and verifying the fs-verity Merkle tree root (and header info) >> signature. This is independent of which filesystems support it. >> >>> >>> The first priority (for me, anyway) therefore is getting the >>> ability to move IMA metadata between NFS clients and servers >>> shoveled into the NFS protocol, but that's been blocked for various >>> legal reasons. >> >> Up to now, verifying remote filesystem file integrity has been out of >> scope for IMA. With fs-verity file signatures I can at least grasp >> how remote file integrity could possibly work. I don't understand >> how remote file integrity with existing IMA formats could be >> supported. You might want to consider writing a whitepaper, which >> could later be used as the basis for a patch set cover letter. > > I think, before this, we can help with the basics (and perhaps we > should sort them out before we start documenting what we'll do). Thanks for the help! I just want to emphasize that documentation (eg, a specification) will be critical for remote filesystems. If any of this is to be supported by a remote filesystem, then we need an unencumbered description of the new metadata format rather than code. GPL-encumbered formats cannot be contributed to the NFS standard, and are probably difficult for other filesystems that are not Linux-native, like SMB, as well. > The > first basic is that a merkle tree allows unit at a time verification. > First of all we should agree on the unit. Since we always fault a page > at a time, I think our merkle tree unit should be a page not a block. Remote filesystems will need to agree that the size of that unit is the same everywhere, or the unit size could be stored in the per-file metadata. > Next, we should agree where the check gates for the per page accesses > should be ... definitely somewhere in readpage, I suspect and finally > we should agree how the merkle tree is presented at the gate. I think > there are three ways: > > 1. Ahead of time transfer: The merkle tree is transferred and verified > at some time before the accesses begin, so we already have a > verified copy and can compare against the lower leaf. > 2. Async transfer: We provide an async mechanism to transfer the > necessary components, so when presented with a unit, we check the > log n components required to get to the root > 3. The protocol actually provides the capability of 2 (like the SCSI > DIF/DIX), so to IMA all the pieces get presented instead of IMA > having to manage the tree A Merkle tree is potentially large enough that it cannot be stored in an extended attribute. In addition, an extended attribute is not a byte stream that you can seek into or read small parts of, it is retrieved in a single shot. For this reason, the idea was to save only the signature of the tree's root on durable storage. The client would retrieve that signature possibly at open time, and reconstruct the tree at that time. Or the tree could be partially constructed on-demand at the time each unit is to be checked (say, as part of 2. above). The client would have to reconstruct that tree again if memory pressure caused some or all of the tree to be evicted, so perhaps an on-demand mechanism is preferable. > There are also a load of minor things like how we get the head hash, > which must be presented and verified ahead of time for each of the > above 3. Also, changes to a file's content and its tree signature are not atomic. If a file is mutable, then there is the period between when the file content has changed and when the signature is updated. Some discussion of how a client is to behave in those situations will be necessary. -- Chuck Lever chucklever@gmail.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chuck Lever Subject: Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE) Date: Mon, 10 Aug 2020 19:36:47 -0400 Message-ID: <6E907A22-02CC-42DD-B3CD-11D304F3A1A8@gmail.com> References: <20200728213614.586312-1-deven.desai@linux.microsoft.com> <20200802115545.GA1162@bug> <20200802140300.GA2975990@sasha-vm> <20200802143143.GB20261@amd> <1596386606.4087.20.camel@HansenPartnership.com> <1596639689.3457.17.camel@HansenPartnership.com> <329E8DBA-049E-4959-AFD4-9D118DEB176E@gmail.com> <1597073737.3966.12.camel@HansenPartnership.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1597073737.3966.12.camel@HansenPartnership.com> Sender: linux-block-owner@vger.kernel.org To: James Bottomley Cc: Mimi Zohar , James Morris , Deven Bowers , Pavel Machek , Sasha Levin , snitzer@redhat.com, dm-devel@redhat.com, tyhicks@linux.microsoft.com, agk@redhat.com, Paul Moore , Jonathan Corbet , nramas@linux.microsoft.com, serge@hallyn.com, pasha.tatashin@soleen.com, Jann Horn , linux-block@vger.kernel.org, Al Viro , Jens Axboe , mdsakib@microsoft.com, open list , eparis@redhat.com, linux-security-module@vger.kernel.org, linux-audit@redhat.com, linux-fsdevel , linux-integrity@vger.kernel.org, jaskarankhurana@linu List-Id: dm-devel.ids > On Aug 10, 2020, at 11:35 AM, James Bottomley = wrote: >=20 > On Sun, 2020-08-09 at 13:16 -0400, Mimi Zohar wrote: >> On Sat, 2020-08-08 at 13:47 -0400, Chuck Lever wrote: >>>> On Aug 5, 2020, at 2:15 PM, Mimi Zohar >>>> wrote: >>=20 >> >>=20 >>>> If block layer integrity was enough, there wouldn't have been a >>>> need for fs-verity. Even fs-verity is limited to read only >>>> filesystems, which makes validating file integrity so much >>>> easier. =46rom the beginning, we've said that fs-verity signatures >>>> should be included in the measurement list. (I thought someone >>>> signed on to add that support to IMA, but have not yet seen >>>> anything.) >>>=20 >>> Mimi, when you and I discussed this during LSS NA 2019, I didn't >>> fully understand that you expected me to implement signed Merkle >>> trees for all filesystems. At the time, it sounded to me like you >>> wanted signed Merkle trees only for NFS files. Is that still the >>> case? >>=20 >> I definitely do not expect you to support signed Merkle trees for all >> filesystems. My interested is from an IMA perspective of measuring >> and verifying the fs-verity Merkle tree root (and header info) >> signature. This is independent of which filesystems support it. >>=20 >>>=20 >>> The first priority (for me, anyway) therefore is getting the >>> ability to move IMA metadata between NFS clients and servers >>> shoveled into the NFS protocol, but that's been blocked for various >>> legal reasons. >>=20 >> Up to now, verifying remote filesystem file integrity has been out of >> scope for IMA. With fs-verity file signatures I can at least grasp >> how remote file integrity could possibly work. I don't understand >> how remote file integrity with existing IMA formats could be >> supported. You might want to consider writing a whitepaper, which >> could later be used as the basis for a patch set cover letter. >=20 > I think, before this, we can help with the basics (and perhaps we > should sort them out before we start documenting what we'll do). Thanks for the help! I just want to emphasize that documentation (eg, a specification) will be critical for remote filesystems. If any of this is to be supported by a remote filesystem, then we need an unencumbered description of the new metadata format rather than code. GPL-encumbered formats cannot be contributed to the NFS standard, and are probably difficult for other filesystems that are not Linux-native, like SMB, as well. > The > first basic is that a merkle tree allows unit at a time verification.=20= > First of all we should agree on the unit. Since we always fault a = page > at a time, I think our merkle tree unit should be a page not a block. Remote filesystems will need to agree that the size of that unit is the same everywhere, or the unit size could be stored in the per-file metadata. > Next, we should agree where the check gates for the per page accesses > should be ... definitely somewhere in readpage, I suspect and finally > we should agree how the merkle tree is presented at the gate. I think > there are three ways: >=20 > 1. Ahead of time transfer: The merkle tree is transferred and = verified > at some time before the accesses begin, so we already have a > verified copy and can compare against the lower leaf. > 2. Async transfer: We provide an async mechanism to transfer the > necessary components, so when presented with a unit, we check the > log n components required to get to the root > 3. The protocol actually provides the capability of 2 (like the SCSI > DIF/DIX), so to IMA all the pieces get presented instead of IMA > having to manage the tree A Merkle tree is potentially large enough that it cannot be stored in an extended attribute. In addition, an extended attribute is not a byte stream that you can seek into or read small parts of, it is retrieved in a single shot. For this reason, the idea was to save only the signature of the tree's root on durable storage. The client would retrieve that signature possibly at open time, and reconstruct the tree at that time. Or the tree could be partially constructed on-demand at the time each unit is to be checked (say, as part of 2. above). The client would have to reconstruct that tree again if memory pressure caused some or all of the tree to be evicted, so perhaps an on-demand mechanism is preferable. > There are also a load of minor things like how we get the head hash, > which must be presented and verified ahead of time for each of the > above 3. Also, changes to a file's content and its tree signature are not atomic. If a file is mutable, then there is the period between when the file content has changed and when the signature is updated. Some discussion of how a client is to behave in those situations will be necessary. -- Chuck Lever chucklever@gmail.com