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, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 92FD4C433E0 for ; Tue, 11 Aug 2020 15:51:20 +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 37D8B20756 for ; Tue, 11 Aug 2020 15:51:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 37D8B20756 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=hansenpartnership.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-277-DDGNi_HQNtKLaW8m5l1WHg-1; Tue, 11 Aug 2020 11:51:16 -0400 X-MC-Unique: DDGNi_HQNtKLaW8m5l1WHg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 89AA81800D41; Tue, 11 Aug 2020 15:51: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 397EA5F1EF; Tue, 11 Aug 2020 15:51: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 435E41809554; Tue, 11 Aug 2020 15:51:08 +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 07BFX2lu023157 for ; Tue, 11 Aug 2020 11:33:03 -0400 Received: by smtp.corp.redhat.com (Postfix) id CF761F4ECD; Tue, 11 Aug 2020 15:33:02 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast04.extmail.prod.ext.rdu2.redhat.com [10.11.55.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C9F42F5561 for ; Tue, 11 Aug 2020 15:32:59 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (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 B1836108C269 for ; Tue, 11 Aug 2020 15:32:59 +0000 (UTC) Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [66.63.167.143]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-217-vUC8em3fO9ahRvhIUnWf8w-1; Tue, 11 Aug 2020 11:32:54 -0400 X-MC-Unique: vUC8em3fO9ahRvhIUnWf8w-1 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id E738F8EE19D; Tue, 11 Aug 2020 08:32:51 -0700 (PDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3YM1B3UJc5Z; Tue, 11 Aug 2020 08:32:51 -0700 (PDT) Received: from [153.66.254.174] (c-73-35-198-56.hsd1.wa.comcast.net [73.35.198.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 7D8168EE149; Tue, 11 Aug 2020 08:32:50 -0700 (PDT) Message-ID: <1597159969.4325.21.camel@HansenPartnership.com> Subject: Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE) From: James Bottomley To: Chuck Lever Date: Tue, 11 Aug 2020 08:32:49 -0700 In-Reply-To: <16C3BF97-A7D3-488A-9D26-7C9B18AD2084@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> <6E907A22-02CC-42DD-B3CD-11D304F3A1A8@gmail.com> <1597124623.30793.14.camel@HansenPartnership.com> <16C3BF97-A7D3-488A-9D26-7C9B18AD2084@gmail.com> Mime-Version: 1.0 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: Tue, 11 Aug 2020 11:51:07 -0400 Cc: snitzer@redhat.com, Deven Bowers , Mimi Zohar , dm-devel@redhat.com, tyhicks@linux.microsoft.com, Pavel Machek , Paul, 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.79 on 10.5.11.15 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 Tue, 2020-08-11 at 10:48 -0400, Chuck Lever wrote: > > On Aug 11, 2020, at 1:43 AM, James Bottomley > > wrote: > > On Mon, 2020-08-10 at 19:36 -0400, Chuck Lever wrote: [...] > > > 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. > > > > I don't understand what you mean by GPL encumbered formats. The > > GPL is a code licence not a data or document licence. > > IETF contributions occur under a BSD-style license incompatible > with the GPL. > > https://trustee.ietf.org/trust-legal-provisions.html > > Non-Linux implementers (of OEM storage devices) rely on such > standards processes to indemnify them against licensing claims. Well, that simply means we won't be contributing the Linux implementation, right? However, IETF doesn't require BSD for all implementations, so that's OK. > Today, there is no specification for existing IMA metadata formats, > there is only code. My lawyer tells me that because the code that > implements these formats is under GPL, the formats themselves cannot > be contributed to, say, the IETF without express permission from the > authors of that code. There are a lot of authors of the Linux IMA > code, so this is proving to be an impediment to contribution. That > blocks the ability to provide a fully-specified NFS protocol > extension to support IMA metadata formats. Well, let me put the counterpoint: I can write a book about how linux device drivers work (which includes describing the data formats), for instance, without having to get permission from all the authors ... or is your lawyer taking the view we should be suing Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman for licence infringement? In fact do they think we now have a huge class action possibility against O'Reilly and a host of other publishers ... > > The way the spec process works in Linux is that we implement or > > evolve a data format under a GPL implementaiton, but that > > implementation doesn't implicate the later standardisation of the > > data format and people are free to reimplement under any licence > > they choose. > > That technology transfer can happen only if all the authors of that > prototype agree to contribute to a standard. That's much easier if > that agreement comes before an implementation is done. The current > IMA code base is more than a decade old, and there are more than a > hundred authors who have contributed to that base. > > Thus IMO we want an unencumbered description of any IMA metadata > format that is to be contributed to an open standards body (as it > would have to be to extend, say, the NFS protocol). Fine, good grief, people who take a sensible view of this can write the data format down and publish it under any licence you like then you can pick it up again safely. Would CC0 be OK? ... neither GPL nor BSD are document licences and we shouldn't perpetuate bad practice by licensing documentation under them. James -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit