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 3B0E7C433DF for ; Wed, 12 Aug 2020 14:18:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 161C120781 for ; Wed, 12 Aug 2020 14:18:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="cRsT2ZGx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726512AbgHLOSq (ORCPT ); Wed, 12 Aug 2020 10:18:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726485AbgHLOSo (ORCPT ); Wed, 12 Aug 2020 10:18:44 -0400 Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8B70C061383; Wed, 12 Aug 2020 07:18:44 -0700 (PDT) Received: by mail-il1-x144.google.com with SMTP id 77so1764476ilc.5; Wed, 12 Aug 2020 07:18:44 -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=48IsAeauuq9BcWaKpHbdNQ/tldBG5RElnWagtcAUqV4=; b=cRsT2ZGxUqGKOyzMO0wNvu9c+MKHGwNtaL6WtkzcJzG2FycOznSzVRew0E6OYHFgux fsIyKPl6ke8ScaAfvjEtSMjX/9nYkikjCzR9HUZnzR8ETeQxqgzT8T9m9tkPZXgOf2rz QTa2ibKV/kc3wjS8YgXlIeurfSfb/bDJCAKxjA45Lso2Ku4KDO7jliyJhWJHeEhDFA7X ReTwAvAMpfx0ApCdtT50EYjARYNFr2Pa0x4ybb5B05UqDaqofUj0hJUWtxBZFJZPdZOq VTjf/jf3xqOmYG2RwMDDkJTrdk7iPHgg2+DhSezRHe/5imOjPJK1QaINlGCpBwHoXiux 1TmA== 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=48IsAeauuq9BcWaKpHbdNQ/tldBG5RElnWagtcAUqV4=; b=jDAFX//wlZ67ADG3BRoc+98oHpeUn1PkrsX26dCVeGKDRRPBup3obeJAuaOiYMIbCR a9iWZ1Ixmd4rKaYTO9a7qUhqRuy3y/hE/klwkuoTnXP38yhvxernDptdOOZ/OPAObcZ0 6VG3d2Xx91WoPNA+E1zpCGTYV3490uFcffflct3GLTVVramOjjnfUfq1HKBva40INeWV 50Qt5h+zszbG5bX2ZM20lLfWXJQzKKtx2iSdyb04CCbjo/lAkVceldBJ4a4gTDdKCafk OuMbd7Wnc/zmu9QEkRuXBCUzVDH2U2jDp6MohoIFcy870Fj1QYhk9LibeVcL82uf/WQ3 hayA== X-Gm-Message-State: AOAM532wUN5rEwsWt789RLQyCVJRltRw3Tr8BCd2LgsN6EC6lldeZk7T ApzeZzY2nQkFsclluTDHq60= X-Google-Smtp-Source: ABdhPJzf/jasvT0zc9p1+CGDgqywSS+wUi9D5ewUAR1wjx5vZ+7v7igbj00P+ikLT5qiFiGJ2YZ2iA== X-Received: by 2002:a92:418b:: with SMTP id o133mr14743047ila.277.1597241924157; Wed, 12 Aug 2020 07:18:44 -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 r8sm1129252ilt.54.2020.08.12.07.18.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2020 07:18:42 -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: Date: Wed, 12 Aug 2020 10:18:41 -0400 Cc: Mimi Zohar , James Bottomley , 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: 7bit Message-Id: <70603A4E-A548-4ECB-97D4-D3102CE77701@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> To: James Morris 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 11, 2020, at 5:03 PM, James Morris wrote: > > On Sat, 8 Aug 2020, Chuck Lever wrote: > >> My interest is in code integrity enforcement for executables stored >> in NFS files. >> >> My struggle with IPE is that due to its dependence on dm-verity, it >> does not seem to able to protect content that is stored separately >> from its execution environment and accessed via a file access >> protocol (FUSE, SMB, NFS, etc). > > It's not dependent on DM-Verity, that's just one possible integrity > verification mechanism, and one of two supported in this initial > version. The other is 'boot_verified' for a verified or otherwise trusted > rootfs. Future versions will support FS-Verity, at least. > > IPE was designed to be extensible in this way, with a strong separation of > mechanism and policy. I got that, but it looked to me like the whole system relied on having access to the block device under the filesystem. That's not possible for a remote filesystem like Ceph or NFS. I'm happy to take a closer look if someone can point me the right way. -- 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 D2BFEC433E0 for ; Wed, 12 Aug 2020 14:28:44 +0000 (UTC) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 59E3620781 for ; Wed, 12 Aug 2020 14:28:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 59E3620781 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-37-qiB0LTPaPtuyskSF-gvkfQ-1; Wed, 12 Aug 2020 10:28:41 -0400 X-MC-Unique: qiB0LTPaPtuyskSF-gvkfQ-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 BD6A385B67C; Wed, 12 Aug 2020 14:28:37 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B499119D7B; Wed, 12 Aug 2020 14:28:36 +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 963B69A02C; Wed, 12 Aug 2020 14:28:36 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 07CEIslM023173 for ; Wed, 12 Aug 2020 10:18:54 -0400 Received: by smtp.corp.redhat.com (Postfix) id 5F707CF636; Wed, 12 Aug 2020 14:18:54 +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 561BBD0187 for ; Wed, 12 Aug 2020 14:18:51 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (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 5F94F18A6676 for ; Wed, 12 Aug 2020 14:18:51 +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-321-Nc5fMAbSOfuSTyIvLDMGNQ-1; Wed, 12 Aug 2020 10:18:45 -0400 X-MC-Unique: Nc5fMAbSOfuSTyIvLDMGNQ-1 Received: by mail-il1-f195.google.com with SMTP id c6so1730287ilo.13; Wed, 12 Aug 2020 07:18:44 -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=48IsAeauuq9BcWaKpHbdNQ/tldBG5RElnWagtcAUqV4=; b=DqWoP014kmbxikDIgYh438d7j4x18/iggHqkR6rbtM27we1YD1t6dNI70plgc/SGSu /AaGhjUgY0fpujwgqq19Mfsu2Ex5YAKc8qnfwv/JgYLFuX68oBIa7ut346m58UKlRE4s WFunxKZfd7PsGGTGctIGPnsLgitge56DHqN3WJnIqgsbVea2Jn8tvPunuCGQSvudjMzh 08Pn/Yk+VObXSpGiaOboxZG0tVSYfkccrwKFngcZ0GavMX2DCrAJ6mNPh0EY4kdQFZC2 +Ec4erwuC41ZPxG+6ZUDRELc99VZ8g3LljrHybDwPsk6im52ehuN0gzKmM5sobhbuVx2 G8zA== X-Gm-Message-State: AOAM531FHxWsS+h0JZixIgJQCjxDN5w67Ju/KkSBYSAwDwa2nUSc18Ny IFC6bsev+ONDuwkOALRSRWc= X-Google-Smtp-Source: ABdhPJzf/jasvT0zc9p1+CGDgqywSS+wUi9D5ewUAR1wjx5vZ+7v7igbj00P+ikLT5qiFiGJ2YZ2iA== X-Received: by 2002:a92:418b:: with SMTP id o133mr14743047ila.277.1597241924157; Wed, 12 Aug 2020 07:18:44 -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 r8sm1129252ilt.54.2020.08.12.07.18.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2020 07:18:42 -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: Date: Wed, 12 Aug 2020 10:18:41 -0400 Message-Id: <70603A4E-A548-4ECB-97D4-D3102CE77701@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> To: James Morris 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.79 on 10.11.54.5 X-loop: linux-audit@redhat.com X-Mailman-Approved-At: Wed, 12 Aug 2020 10:28:28 -0400 Cc: snitzer@redhat.com, Deven Bowers , Mimi Zohar , James Bottomley , dm-devel@redhat.com, tyhicks@linux.microsoft.com, Pavel Machek , agk@redhat.com, Sasha Levin , 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 , 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.501 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > On Aug 11, 2020, at 5:03 PM, James Morris wrote: > > On Sat, 8 Aug 2020, Chuck Lever wrote: > >> My interest is in code integrity enforcement for executables stored >> in NFS files. >> >> My struggle with IPE is that due to its dependence on dm-verity, it >> does not seem to able to protect content that is stored separately >> from its execution environment and accessed via a file access >> protocol (FUSE, SMB, NFS, etc). > > It's not dependent on DM-Verity, that's just one possible integrity > verification mechanism, and one of two supported in this initial > version. The other is 'boot_verified' for a verified or otherwise trusted > rootfs. Future versions will support FS-Verity, at least. > > IPE was designed to be extensible in this way, with a strong separation of > mechanism and policy. I got that, but it looked to me like the whole system relied on having access to the block device under the filesystem. That's not possible for a remote filesystem like Ceph or NFS. I'm happy to take a closer look if someone can point me the right way. -- 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: Wed, 12 Aug 2020 10:18:41 -0400 Message-ID: <70603A4E-A548-4ECB-97D4-D3102CE77701@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> 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: 7bit Return-path: In-Reply-To: Sender: linux-block-owner@vger.kernel.org To: James Morris Cc: Mimi Zohar , James Bottomley , 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.or List-Id: dm-devel.ids > On Aug 11, 2020, at 5:03 PM, James Morris wrote: > > On Sat, 8 Aug 2020, Chuck Lever wrote: > >> My interest is in code integrity enforcement for executables stored >> in NFS files. >> >> My struggle with IPE is that due to its dependence on dm-verity, it >> does not seem to able to protect content that is stored separately >> from its execution environment and accessed via a file access >> protocol (FUSE, SMB, NFS, etc). > > It's not dependent on DM-Verity, that's just one possible integrity > verification mechanism, and one of two supported in this initial > version. The other is 'boot_verified' for a verified or otherwise trusted > rootfs. Future versions will support FS-Verity, at least. > > IPE was designed to be extensible in this way, with a strong separation of > mechanism and policy. I got that, but it looked to me like the whole system relied on having access to the block device under the filesystem. That's not possible for a remote filesystem like Ceph or NFS. I'm happy to take a closer look if someone can point me the right way. -- Chuck Lever chucklever@gmail.com