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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 EDE5AC47093 for ; Wed, 2 Jun 2021 15:14:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D985C61360 for ; Wed, 2 Jun 2021 15:14:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231695AbhFBPQX (ORCPT ); Wed, 2 Jun 2021 11:16:23 -0400 Received: from mail-ej1-f49.google.com ([209.85.218.49]:42715 "EHLO mail-ej1-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231286AbhFBPQW (ORCPT ); Wed, 2 Jun 2021 11:16:22 -0400 Received: by mail-ej1-f49.google.com with SMTP id qq22so4357398ejb.9 for ; Wed, 02 Jun 2021 08:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+J7KF4ks9US2bAffAcsOJQKFyjMfB4gR4lgzzMSLNYI=; b=igpuWRlb73xmxahkSHaMuUjyZe1AZUKePohe+4Fi/InrT6JxVOc8e91F5osWhaSLgX E84EkXnpmXUZMoleQY1TbZkS7zMEZN4+HXy889QAxq82OaDUCta8mDCg+CDFR0S68+/f DwY+xH9cCE0L/2BTW7CmtzXLbJ0WcObPFs2rxeOAsHButkL/MPV4qN+JjL3+3vK+FmR2 Tme3hvmLA2IKH5aKNG7E7QJEpZrATS6Njz5FrIOFpBzua8jgqkDvKqiu000m3hQ5f23y nyETPrIfZtVbKPopwrFxW+VhJEa29oaIO9TR9M3v2rjZnVsDs06ghXOLkpMzEgh7PvwR gZgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+J7KF4ks9US2bAffAcsOJQKFyjMfB4gR4lgzzMSLNYI=; b=nMG3Ro66spq8EC/1qNvCjgnOz3CugsPgcfR7HqCD8wOKFWBsnRFu3b/+v1zFUScfar 2oO+byUmzAHK5D9p7E9ldznbiIYSn24vN/auiSFR7+sGp18IZ/s3eeRQwmAPuIsN2hxI HjgEMRWCYOOh5piRQeTI9WW8WSigz9OWBIDgW48xxvfrTjQbiqskrYiU7itjxK/IoKps Ms3XsYYE7YRxfDHbAUp6L6JuoZ37X/GWxFVZw8nDUMWLRTVEoN3vbRhS+xcnkXDXKwxG qDsQ0RY4UuX9K6cms7GNDoh9cOBfBDkvEtJmHyhw9bPFsQ736rCwlM2fGoAX77Ia7ieH hTSw== X-Gm-Message-State: AOAM533MXYoprCEUmotBDRf2/RZUKhb9xGyBP1oplCZbQfeNdNFuS0ol x0Im5HtehjdllMtIcbE2/i9BJDkD19+DjXQEoXSs X-Google-Smtp-Source: ABdhPJwFomdKMYZxRrY9ExJPtl6HzjR84K/gicCWfDx/868bcJc4eB2tlYYJNUFzU5Q4QC96WaC2lUPEqPL7r6AtsDo= X-Received: by 2002:a17:906:2c54:: with SMTP id f20mr17365763ejh.91.1622646818352; Wed, 02 Jun 2021 08:13:38 -0700 (PDT) MIME-Version: 1.0 References: <20210517092006.803332-1-omosnace@redhat.com> <01135120-8bf7-df2e-cff0-1d73f1f841c3@iogearbox.net> <2e541bdc-ae21-9a07-7ac7-6c6a4dda09e8@iogearbox.net> <3ca181e3-df32-9ae0-12c6-efb899b7ce7a@iogearbox.net> In-Reply-To: <3ca181e3-df32-9ae0-12c6-efb899b7ce7a@iogearbox.net> From: Paul Moore Date: Wed, 2 Jun 2021 11:13:27 -0400 Message-ID: Subject: Re: [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks To: Daniel Borkmann Cc: Ondrej Mosnacek , linux-security-module@vger.kernel.org, James Morris , Steven Rostedt , Ingo Molnar , Stephen Smalley , selinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Casey Schaufler , jolsa@redhat.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 2, 2021 at 8:40 AM Daniel Borkmann wrote: > On 6/1/21 10:47 PM, Paul Moore wrote: > > The thing I'm worried about would be the case where a LSM policy > > change requires that an existing BPF program be removed or disabled. > > I'm guessing based on the refcounting that there is not presently a > > clean way to remove a BPF program from the system, but is this > > something we could resolve? If we can't safely remove a BPF program > > from the system, can we replace/swap it with an empty/NULL BPF > > program? > > Removing progs would somehow mean destroying those references from an > async event and then /safely/ guaranteeing that nothing is accessing > them anymore. But then if policy changes once more where they would > be allowed again we would need to revert back to the original state, > which brings us to your replace/swap question with an empty/null prog. > It's not feasible either, because there are different BPF program types > and they can have different return code semantics that lead to subsequent > actions. If we were to replace them with an empty/NULL program, then > essentially this will get us into an undefined system state given it's > unclear what should be a default policy for each program type, etc. > Just to pick one simple example, outside of tracing, that comes to mind: > say, you attached a program with tc to a given device ingress hook. That > program implements firewalling functionality, and potentially deep down > in that program there is functionality to record/sample packets along > with some meta data. Part of what is exported to the ring buffer to the > user space reader may be a struct net_device field that is otherwise not > available (or at least not yet), hence it's probe-read with mentioned > helpers. If you were now to change the SELinux policy for that tc loader > application, and therefore replace/swap the progs in the kernel that were > loaded with it (given tc's lockdown policy was recorded in their sec blob) > with an empty/NULL program, then either you say allow-all or drop-all, > but either way, you break the firewalling functionality completely by > locking yourself out of the machine or letting everything through. There > is no sane way where we could reason about the context/internals of a > given program where it would be safe to replace with a simple empty/NULL > prog. Help me out here, is your answer that the access check can only be done at BPF program load time? That isn't really a solution from a SELinux perspective as far as I'm concerned. I understand the ideas I've tossed out aren't practical from a BPF perspective, but it would be nice if we could find something that does work. Surely you BPF folks can think of some way to provide a runtime, not load time, check? -- paul moore www.paul-moore.com