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 28A04C433E0 for ; Wed, 12 Aug 2020 15:22:14 +0000 (UTC) Received: from us-smtp-delivery-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 mail.kernel.org (Postfix) with ESMTPS id C199420829 for ; Wed, 12 Aug 2020 15:22:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C199420829 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-337-2ZXrXTIfOhGOf5Ta9nACqw-1; Wed, 12 Aug 2020 11:22:06 -0400 X-MC-Unique: 2ZXrXTIfOhGOf5Ta9nACqw-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 B5FED800D55; Wed, 12 Aug 2020 15:22:02 +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 6CE135D6BD; Wed, 12 Aug 2020 15:22:02 +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 26D0E181A870; Wed, 12 Aug 2020 15:22:00 +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 07CEkBAJ027451 for ; Wed, 12 Aug 2020 10:46:11 -0400 Received: by smtp.corp.redhat.com (Postfix) id A881A2026D69; Wed, 12 Aug 2020 14:46:11 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast01.extmail.prod.ext.rdu2.redhat.com [10.11.55.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A3B932026D5D for ; Wed, 12 Aug 2020 14:46:09 +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 mimecast-mx02.redhat.com (Postfix) with ESMTPS id 79517857028 for ; Wed, 12 Aug 2020 14:46:09 +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-152-YT8_bUNjOSKskT-JC_DIWQ-1; Wed, 12 Aug 2020 10:46:01 -0400 X-MC-Unique: YT8_bUNjOSKskT-JC_DIWQ-1 Received: by mail-il1-f195.google.com with SMTP id l7so1864960ils.2; Wed, 12 Aug 2020 07:46:00 -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=kQOJV8hQKKWi1Q4IBwonjxI4nlnYdAyxL48CghY2b34=; b=b+BykxfZZy/GfxG3ZsY89aLaC7crjoKmrrh7Zy3E0QF77E9rszX2VQPGD/TBRIlYLR 34Gy8YSv/EdVQPNJmUDqOdWtCCb+fHlytViJZBppRKT1ahuK2sCdlnGkPmiyh21OE+8A B+uDaOcBZGFVErTk+m+BmahPtFmKk5pQ25BPHBTYaDS9rSu/azN1Zxt8roQrlWXFJ5ri lAX3xW6do4NLZJBpLKCzaoRyGGH/Cwno7LwLx4N0L0j5zgF6XFIpTsNMoDnKNypoymC/ 6CUDgtsP3I9Gkc5iGFiFoxnLwd9AoljSrIjtZ2Me0dM/8cSIuQKlENLg1EZYIGR/VhpM p/uA== X-Gm-Message-State: AOAM530y7PNw6yy7sUlaluAsqwfSjRzJ3EbNOKjSR9ijedxqnq2bZMQP Vq/2phhCLkMMpKcXsrfKhkc= X-Google-Smtp-Source: ABdhPJwhgRbaRRSqe0vcGsrFV97VYVYstE/PFYHOorVWwg7UGiBOlCHPQtwmMYxo8Rf89OCc3e2t5w== X-Received: by 2002:a92:6d0c:: with SMTP id i12mr8272ilc.37.1597243558796; Wed, 12 Aug 2020 07:45:58 -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 k14sm1089731ion.17.2020.08.12.07.45.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2020 07:45:57 -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: <1597159969.4325.21.camel@HansenPartnership.com> Date: Wed, 12 Aug 2020 10:45:56 -0400 Message-Id: <20F82AFA-D0AC-479B-AB1D-0D354AE19498@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> <1597159969.4325.21.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 07CEkBAJ027451 X-loop: linux-audit@redhat.com X-Mailman-Approved-At: Wed, 12 Aug 2020 11:21:59 -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.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 Aug 11, 2020, at 11:32 AM, James Bottomley wrote: > > 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? At the present time, there is nothing but the Linux implementation. There's no English description, there's no specification of the formats, the format is described only by source code. The only way to contribute current IMA metadata formats to an open standards body like the IETF is to look at encumbered code first. We would effectively be contributing an implementation in this case. (I'm not saying the current formats should or should not be contributed; merely that there is a legal stumbling block to doing so that can be avoided for newly defined formats). > Well, let me put the counterpoint: I can write a book about how linux > device drivers work (which includes describing the data formats) Our position is that someone who reads that book and implements those formats under a non-GPL-compatible license would be in breach of the GPL. The point of the standards process is to indemnify implementing and distributing under _any_ license what has been published by the standards body. That legally enables everyone to use the published protocol/format in their own code no matter how it happens to be licensed. > 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. That's what I proposed. Write it down under the IETF Trust legal provisions license. And I volunteered to do that. All I'm saying is that description needs to come before code. -- Chuck Lever chucklever@gmail.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit