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=-5.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 3F15AC4708F for ; Mon, 31 May 2021 08:24:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 23BAC6127A for ; Mon, 31 May 2021 08:24:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230523AbhEaI0Y (ORCPT ); Mon, 31 May 2021 04:26:24 -0400 Received: from www62.your-server.de ([213.133.104.62]:50348 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230428AbhEaIZ7 (ORCPT ); Mon, 31 May 2021 04:25:59 -0400 Received: from sslproxy05.your-server.de ([78.46.172.2]) by www62.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1lndDX-000FgJ-MR; Mon, 31 May 2021 10:24:11 +0200 Received: from [85.7.101.30] (helo=linux-2.home) by sslproxy05.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lndDX-000Gza-CF; Mon, 31 May 2021 10:24:11 +0200 Subject: Re: [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks To: Paul Moore 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 References: <20210517092006.803332-1-omosnace@redhat.com> <01135120-8bf7-df2e-cff0-1d73f1f841c3@iogearbox.net> From: Daniel Borkmann Message-ID: <2e541bdc-ae21-9a07-7ac7-6c6a4dda09e8@iogearbox.net> Date: Mon, 31 May 2021 10:24:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.103.2/26186/Sun May 30 13:11:19 2021) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/29/21 8:48 PM, Paul Moore wrote: [...] > Daniel's patch side steps that worry by just doing the lockdown > permission check when the BPF program is loaded, but that isn't a > great solution if the policy changes afterward. I was hoping there > might be some way to perform the permission check as needed, but the > more I look the more that appears to be difficult, if not impossible > (once again, corrections are welcome). Your observation is correct, will try to clarify below a bit. > I'm now wondering if the right solution here is to make use of the LSM > notifier mechanism. I'm not yet entirely sure if this would work from > a BPF perspective, but I could envision the BPF subsystem registering > a LSM notification callback via register_blocking_lsm_notifier(), see > if Infiniband code as an example, and then when the LSM(s) policy > changes the BPF subsystem would get a notification and it could > revalidate the existing BPF programs and take block/remove/whatever > the offending BPF programs. This obviously requires a few things > which I'm not sure are easily done, or even possible: > > 1. Somehow the BPF programs would need to be "marked" at > load/verification time with respect to their lockdown requirements so > that decisions can be made later. Perhaps a flag in bpf_prog_aux? > > 2. While it looks like it should be possible to iterate over all of > the loaded BPF programs in the LSM notifier callback via > idr_for_each(prog_idr, ...), it is not clear to me if it is possible > to safely remove, or somehow disable, BPF programs once they have been > loaded. Hopefully the BPF folks can help answer that question. > > 3. Disabling of BPF programs might be preferable to removing them > entirely on LSM policy changes as it would be possible to make the > lockdown state less restrictive at a future point in time, allowing > for the BPF program to be executed again. Once again, not sure if > this is even possible. Part of why this gets really complex/impossible is that BPF programs in the kernel are reference counted from various sides, be it that there are references from user space to them (fd from application, BPF fs, or BPF links), hooks where they are attached to as well as tail call maps where one BPF prog calls into another. There is currently also no global infra of some sort where you could piggy back to atomically keep track of all the references in a list or such. And the other thing is that BPF progs have no ownership that is tied to a specific task after they have been loaded. Meaning, once they are loaded into the kernel by an application and attached to a specific hook, they can remain there potentially until reboot of the node, so lifecycle of the user space application != lifecycle of the BPF program. It's maybe best to compare this aspect to kernel modules in the sense that you have an application that loads it into the kernel (insmod, etc, where you could also enforce lockdown signature check), but after that, they can be managed by other entities as well (implicitly refcounted from kernel, removed by other applications, etc). My understanding of the lockdown settings are that users have options to select/enforce a lockdown level of CONFIG_LOCK_DOWN_KERNEL_FORCE_{INTEGRITY, CONFIDENTIALITY} at compilation time, they have a lockdown={integrity| confidentiality} boot-time parameter, /sys/kernel/security/lockdown, and then more fine-grained policy via 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown"). Once you have set a global policy level, you cannot revert back to a less strict mode. So the SELinux policy is specifically tied around tasks to further restrict applications in respect to the global policy. I presume that would mean for those users that majority of tasks have the confidentiality option set via SELinux with just a few necessary using the integrity global policy. So overall the enforcing option when BPF program is loaded is the only really sensible option to me given only there we have the valid current task where such policy can be enforced. Best, Daniel 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=-5.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 75CC5C4708F for ; Mon, 31 May 2021 08:25:01 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 987A1610A8 for ; Mon, 31 May 2021 08:25:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 987A1610A8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=iogearbox.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4FtpHv0wqqz2ylk for ; Mon, 31 May 2021 18:24:59 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=iogearbox.net (client-ip=213.133.104.62; helo=www62.your-server.de; envelope-from=daniel@iogearbox.net; receiver=) Received: from www62.your-server.de (www62.your-server.de [213.133.104.62]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4FtpHT4M2pz2xff for ; Mon, 31 May 2021 18:24:35 +1000 (AEST) Received: from sslproxy05.your-server.de ([78.46.172.2]) by www62.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1lndDX-000FgJ-MR; Mon, 31 May 2021 10:24:11 +0200 Received: from [85.7.101.30] (helo=linux-2.home) by sslproxy05.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lndDX-000Gza-CF; Mon, 31 May 2021 10:24:11 +0200 Subject: Re: [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks To: Paul Moore References: <20210517092006.803332-1-omosnace@redhat.com> <01135120-8bf7-df2e-cff0-1d73f1f841c3@iogearbox.net> From: Daniel Borkmann Message-ID: <2e541bdc-ae21-9a07-7ac7-6c6a4dda09e8@iogearbox.net> Date: Mon, 31 May 2021 10:24:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.103.2/26186/Sun May 30 13:11:19 2021) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: jolsa@redhat.com, selinux@vger.kernel.org, netdev@vger.kernel.org, Stephen Smalley , Ondrej Mosnacek , Steven Rostedt , James Morris , Casey Schaufler , linux-security-module@vger.kernel.org, Ingo Molnar , linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 5/29/21 8:48 PM, Paul Moore wrote: [...] > Daniel's patch side steps that worry by just doing the lockdown > permission check when the BPF program is loaded, but that isn't a > great solution if the policy changes afterward. I was hoping there > might be some way to perform the permission check as needed, but the > more I look the more that appears to be difficult, if not impossible > (once again, corrections are welcome). Your observation is correct, will try to clarify below a bit. > I'm now wondering if the right solution here is to make use of the LSM > notifier mechanism. I'm not yet entirely sure if this would work from > a BPF perspective, but I could envision the BPF subsystem registering > a LSM notification callback via register_blocking_lsm_notifier(), see > if Infiniband code as an example, and then when the LSM(s) policy > changes the BPF subsystem would get a notification and it could > revalidate the existing BPF programs and take block/remove/whatever > the offending BPF programs. This obviously requires a few things > which I'm not sure are easily done, or even possible: > > 1. Somehow the BPF programs would need to be "marked" at > load/verification time with respect to their lockdown requirements so > that decisions can be made later. Perhaps a flag in bpf_prog_aux? > > 2. While it looks like it should be possible to iterate over all of > the loaded BPF programs in the LSM notifier callback via > idr_for_each(prog_idr, ...), it is not clear to me if it is possible > to safely remove, or somehow disable, BPF programs once they have been > loaded. Hopefully the BPF folks can help answer that question. > > 3. Disabling of BPF programs might be preferable to removing them > entirely on LSM policy changes as it would be possible to make the > lockdown state less restrictive at a future point in time, allowing > for the BPF program to be executed again. Once again, not sure if > this is even possible. Part of why this gets really complex/impossible is that BPF programs in the kernel are reference counted from various sides, be it that there are references from user space to them (fd from application, BPF fs, or BPF links), hooks where they are attached to as well as tail call maps where one BPF prog calls into another. There is currently also no global infra of some sort where you could piggy back to atomically keep track of all the references in a list or such. And the other thing is that BPF progs have no ownership that is tied to a specific task after they have been loaded. Meaning, once they are loaded into the kernel by an application and attached to a specific hook, they can remain there potentially until reboot of the node, so lifecycle of the user space application != lifecycle of the BPF program. It's maybe best to compare this aspect to kernel modules in the sense that you have an application that loads it into the kernel (insmod, etc, where you could also enforce lockdown signature check), but after that, they can be managed by other entities as well (implicitly refcounted from kernel, removed by other applications, etc). My understanding of the lockdown settings are that users have options to select/enforce a lockdown level of CONFIG_LOCK_DOWN_KERNEL_FORCE_{INTEGRITY, CONFIDENTIALITY} at compilation time, they have a lockdown={integrity| confidentiality} boot-time parameter, /sys/kernel/security/lockdown, and then more fine-grained policy via 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown"). Once you have set a global policy level, you cannot revert back to a less strict mode. So the SELinux policy is specifically tied around tasks to further restrict applications in respect to the global policy. I presume that would mean for those users that majority of tasks have the confidentiality option set via SELinux with just a few necessary using the integrity global policy. So overall the enforcing option when BPF program is loaded is the only really sensible option to me given only there we have the valid current task where such policy can be enforced. Best, Daniel