Received: by 2002:a05:6358:53a8:b0:117:f937:c515 with SMTP id z40csp4474655rwe; Mon, 17 Apr 2023 13:17:21 -0700 (PDT) X-Google-Smtp-Source: AKy350b1eFWMyJa+lXaPv6sdUO3rBd96rI+SZNfojmQKeMY2vlw9DMKONVMJN0/8N7b5KZ8ok6P0 X-Received: by 2002:a05:6a20:3d8c:b0:ee:e0d8:515d with SMTP id s12-20020a056a203d8c00b000eee0d8515dmr12029486pzi.46.1681762640973; Mon, 17 Apr 2023 13:17:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681762640; cv=none; d=google.com; s=arc-20160816; b=oKlkhaA+C5wl7WR78PH23yfUW6qA15j8S+8T+IiKAq2183ZN/fYqE6jtiQdI3dOM0f FybPD63lqX2mwNZyAa7dJyz20i8jgRRdX0P+qRS4KZ3tKJRsYb2+6UXCxd9f0u/IlCVr hfZInKImE8wZUaxsJNJu4Bl68LUNzTgBVXTxvBFOaKT3H9nIONfQvcXO/zW/UKbLqZfC PCY2kzqvP/E1WWho5AVIAISTN+Nmd2u/Ez1ylhXqFrjDoFFrUn86UXmr36ToEOSstfKV AM0L554wO7B8iDFHh6NuBIwiGbBllRJJ6q8eW69weCTfjE/bDWqUh6C7tP3jHf+9M7kq ZXgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=mkFM4OddDI3MzXQTdAgqfF3VU3F/+LgzOjoA+7s8XA4=; b=dXtFfmevhMw8cO1jCCFuuDvzQHA76tC/cq6IVhA+iXk2D8KVvozPzdqgPNpsTQtsG3 SvDVllyJOaVT6OSaIf9NR0snLZ1SlbRrjf+rYXTzWE+G0s5uLsWd/59O13i41vBOr1Xk 55nGMFQVuO/nSxb6/t0K4usiBZ4pwKwUxLVsw+PQKfmWOySp08bFKvPy4iI0w1/D0P+x Hu7oHXOV57WMLm9tg0VzPw4Ghr6zpfSWrRpGvQuteC+eAFe+tvYnAfY0MSAq/tEBxTbM BQt3lkr8pwWcpEjmoqV8p3kaCg6P48NWw1GSbVwFRdvj0y1mJAhTZUsZ4mqdxZtjGY1h 0LLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore.com header.s=google header.b=Ml35Br1S; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=paul-moore.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j3-20020a654303000000b00513af1fa0b5si12228403pgq.797.2023.04.17.13.17.09; Mon, 17 Apr 2023 13:17:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore.com header.s=google header.b=Ml35Br1S; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=paul-moore.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229769AbjDQUQp (ORCPT + 99 others); Mon, 17 Apr 2023 16:16:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229828AbjDQUQo (ORCPT ); Mon, 17 Apr 2023 16:16:44 -0400 Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1BD749D9 for ; Mon, 17 Apr 2023 13:16:41 -0700 (PDT) Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-54fbee98814so182788287b3.8 for ; Mon, 17 Apr 2023 13:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; t=1681762600; x=1684354600; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mkFM4OddDI3MzXQTdAgqfF3VU3F/+LgzOjoA+7s8XA4=; b=Ml35Br1S4fB3lQjg+85g3UBuNpD2qRSHHrPy7eSM2cIKJ0UHgLPilBvXvoOd26NpVQ XScr4M6uxDpgNOv8wz3lwCYE24jCZFRGgOvMfIhHkdttvMie4TqlWXyoZi7H5u5YSb/G jW/p817xKSmzxkgQXaPUdAbZpNp4DpLIB3lm+1FhoqzLTLUUqTavEQlTtnPv9HlQ8HMQ e119/w9x96Z3IkM9ZXV6zNWtzvuCmN5sJD3GY4c5m6weNq50I9GDsXzCjT4/5MAIWwbl /EqEfWvaLjxUeqvn7BVtzYa97LE8hT7Mu7aE7S+4t84d0NzWjqskd+G/HvvL/AJivftr B7xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681762600; x=1684354600; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mkFM4OddDI3MzXQTdAgqfF3VU3F/+LgzOjoA+7s8XA4=; b=hbDE70ETsrTWLm+6Syj+uCrqsEpDrdaAdhbdOHWMLQttsS4E2LQEHuTIUjmFSMr3g5 YFIjjsqGX5GSy8trLRwE/v3T8wfn7rh2QpB184Upe8ZQ/KsiRufvw6WpRSwmFlG3p3Ic kdIn3cIei+BSZVQoJaWfoa1Fiz0w0qv1qtzGdelTsbDVGvskPLBccsi1HKq5nXCBhez4 3JKvTDg24HuQ4f7X2gL1/opcGukK7N/wXuHyQ0jMr5V4BaQdAd02bnr+z9Su0fXPbUuW ck3M5eWUbU4xx9N+swJfgabb5NVumZwe57xQXX2Xi9KVxySQ2mt3GDYmOQkWUWP+sJK2 WVEg== X-Gm-Message-State: AAQBX9clB2rfNS9wiIYKq7Z9u8923lbaYt/66dbi1OE12YH3ohFEb2V1 /KfyiFw1XIeYdfJXPFak9ajMBM02LiHZ9Tycfa1f X-Received: by 2002:a81:4524:0:b0:54f:aa4b:100c with SMTP id s36-20020a814524000000b0054faa4b100cmr9804160ywa.8.1681762600389; Mon, 17 Apr 2023 13:16:40 -0700 (PDT) MIME-Version: 1.0 References: <1675119451-23180-1-git-send-email-wufan@linux.microsoft.com> <1675119451-23180-6-git-send-email-wufan@linux.microsoft.com> <20230410191035.GB18827@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20230412233606.GA16658@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20230417180605.GA402@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> In-Reply-To: <20230417180605.GA402@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: Paul Moore Date: Mon, 17 Apr 2023 16:16:29 -0400 Message-ID: Subject: Re: [RFC PATCH v9 05/16] ipe: add userspace interface To: Fan Wu Cc: corbet@lwn.net, zohar@linux.ibm.com, jmorris@namei.org, serge@hallyn.com, tytso@mit.edu, ebiggers@kernel.org, axboe@kernel.dk, agk@redhat.com, snitzer@kernel.org, eparis@redhat.com, linux-doc@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-block@vger.kernel.org, dm-devel@redhat.com, linux-audit@redhat.com, roberto.sassu@huawei.com, linux-kernel@vger.kernel.org, Deven Bowers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 17, 2023 at 2:06=E2=80=AFPM Fan Wu = wrote: > On Thu, Apr 13, 2023 at 02:45:07PM -0400, Paul Moore wrote: > > On Wed, Apr 12, 2023 at 7:36???PM Fan Wu wr= ote: > > > On Tue, Apr 11, 2023 at 05:45:41PM -0400, Paul Moore wrote: > > > > On Mon, Apr 10, 2023 at 3:10???PM Fan Wu wrote: > > > > > On Thu, Mar 02, 2023 at 02:04:42PM -0500, Paul Moore wrote: > > > > > > On Mon, Jan 30, 2023 at 5:58???PM Fan Wu wrote: > > > > ... > > > > > > I guess this does make me wonder about keeping a non-active policy > > > > loaded in the kernel, what purpose does that serve? > > > > > > > > > > The non-active policy doesn't serve anything unless it is activated. = User can > > > even delete a policy if that is no longer needed. Non-active is just = the default > > > state when a new policy is loaded. > > > > > > If IPE supports namespace, there is another use case where different = containers > > > can select different policies as the active policy from among multipl= e loaded > > > policies. Deven has presented a demo of this during LSS 2021. But thi= s goes > > > beyond the scope of this version. > > > > Do you plan to add namespace support at some point in the > > not-too-distant future? If so, I'm okay with keeping support for > > multiple policies, but if you think you're only going to support one > > active policy at a time, it might be better to remove support for > > multiple (inactive) policies. > > > > -- > > paul-moore.com > > Another benefit of having multiple policies is that it provides isolation > between different policies. For instance, if we have two policies named > "policy_a" and "policy_b," we can ensure that only team a can update "pol= icy_a," > and only team b can update "policy_b." This way, both teams can update > their policy without affecting others. However, if there is only one poli= cy > in the system, both teams will have to operate on the same policy, making= it > less manageable. That only really matters if both policies are active at the same time; if only one policy can be active at one point in time the only permission that matters is the one who can load/activate a policy. Allowing for multiple policies complicates the code. If there is another feature that requires multiple policies, e.g. IPE namespaces, then that is okay. However, if there is no feature which requires multiple active policies, supporting multiple loaded policies only increases the risk of an exploitable bug in the IPE code. > Besides, removing multiple (inactive) policies support will > render the policy_name field meaningless, and we should only audit the po= licy > hash. I am fine if we decide to go for the single policy option. Once again, I think it comes back to: do you still want to support IPE namespaces at some point in the future, and if so, when do you expect to work on that? --=20 paul-moore.com