From: KP Singh <kpsingh@kernel.org> To: Casey Schaufler <casey@schaufler-ca.com> Cc: Roberto Sassu <roberto.sassu@huawei.com>, Djalal Harouni <tixxdz@gmail.com>, Alexei Starovoitov <alexei.starovoitov@gmail.com>, "corbet@lwn.net" <corbet@lwn.net>, "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>, "ast@kernel.org" <ast@kernel.org>, "daniel@iogearbox.net" <daniel@iogearbox.net>, "andrii@kernel.org" <andrii@kernel.org>, "shuah@kernel.org" <shuah@kernel.org>, "mcoquelin.stm32@gmail.com" <mcoquelin.stm32@gmail.com>, "alexandre.torgue@foss.st.com" <alexandre.torgue@foss.st.com>, "zohar@linux.ibm.com" <zohar@linux.ibm.com>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "bpf@vger.kernel.org" <bpf@vger.kernel.org>, "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>, "linux-stm32@st-md-mailman.stormreply.com" <linux-stm32@st-md-mailman.stormreply.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>, "linux-security-module@vger.kernel.org" <linux-security-module@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 00/18] bpf: Secure and authenticated preloading of eBPF programs Date: Tue, 5 Apr 2022 18:37:42 +0200 [thread overview] Message-ID: <CACYkzJ4KwWykYjb0DJ1SHe9syiefqgfjDB8om7RNx10vZ3UiKg@mail.gmail.com> (raw) In-Reply-To: <fb804242-da2c-4213-9dc3-f09ea42f0355@schaufler-ca.com> On Tue, Apr 5, 2022 at 6:22 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > > On 4/5/2022 8:29 AM, Roberto Sassu wrote: > >> From: Casey Schaufler [mailto:casey@schaufler-ca.com] > >> Sent: Tuesday, April 5, 2022 4:50 PM > >> On 4/4/2022 10:20 AM, Roberto Sassu wrote: > >>>> From: Djalal Harouni [mailto:tixxdz@gmail.com] > >>>> Sent: Monday, April 4, 2022 9:45 AM > >>>> On Sun, Apr 3, 2022 at 5:42 PM KP Singh <kpsingh@kernel.org> wrote: > >>>>> On Sat, Apr 2, 2022 at 1:55 AM Alexei Starovoitov > >>>>> <alexei.starovoitov@gmail.com> wrote: > >>>> ... > >>>>>>> Pinning > >>>>>>> them to unreachable inodes intuitively looked the > >>>>>>> way to go for achieving the stated goal. > >>>>>> We can consider inodes in bpffs that are not unlinkable by root > >>>>>> in the future, but certainly not for this use case. > >>>>> Can this not be already done by adding a BPF_LSM program to the > >>>>> inode_unlink LSM hook? > >>>>> > >>>> Also, beside of the inode_unlink... and out of curiosity: making > >> sysfs/bpffs/ > >>>> readonly after pinning, then using bpf LSM hooks > >>>> sb_mount|remount|unmount... > >>>> family combining bpf() LSM hook... isn't this enough to: > >>>> 1. Restrict who can pin to bpffs without using a full MAC > >>>> 2. Restrict who can delete or unmount bpf filesystem > >>>> > >>>> ? > >>> I'm thinking to implement something like this. > >>> > >>> First, I add a new program flag called > >>> BPF_F_STOP_ONCONFIRM, which causes the ref count > >>> of the link to increase twice at creation time. In this way, > >>> user space cannot make the link disappear, unless a > >>> confirmation is explicitly sent via the bpf() system call. > >>> > >>> Another advantage is that other LSMs can decide > >>> whether or not they allow a program with this flag > >>> (in the bpf security hook). > >>> > >>> This would work regardless of the method used to > >>> load the eBPF program (user space or kernel space). > >>> > >>> Second, I extend the bpf() system call with a new > >>> subcommand, BPF_LINK_CONFIRM_STOP, which > >>> decreasres the ref count for the link of the programs > >>> with the BPF_F_STOP_ONCONFIRM flag. I will also > >>> introduce a new security hook (something like > >>> security_link_confirm_stop), so that an LSM has the > >>> opportunity to deny the stop (the bpf security hook > >>> would not be sufficient to determine exactly for > >>> which link the confirmation is given, an LSM should > >>> be able to deny the stop for its own programs). > >> Would you please stop referring to a set of eBPF programs > >> loaded into the BPF LSM as an LSM? Call it a BPF security > >> module (BSM) if you must use an abbreviation. An LSM is a > >> provider of security_ hooks. In your case that is BPF. When > >> you call the set of eBPF programs an LSM it is like calling > >> an SELinux policy an LSM. > > An eBPF program could be a provider of security_ hooks > > too. > > No, it can't. If I look in /sys/kernel/security/lsm what > you see is "bpf". The LSM is BPF. What BPF does in its > hooks is up to it and its responsibility. > > > The bpf LSM is an aggregator, similarly to your > > infrastructure to manage built-in LSMs. Maybe, calling > > it second-level LSM or secondary LSM would better > > represent this new class. > > It isn't an LSM, and adding a qualifier doesn't make it > one and only adds to the confusion. > > > The only differences are the registration method, (SEC > > directive instead of DEFINE_LSM), and what the hook > > implementation can access. > > Those two things pretty well define what an LSM is. > > > The implementation of a security_ hook via eBPF can > > follow the same structure of built-in LSMs, i.e. it can be > > uniquely responsible for enforcing and be policy-agnostic, > > and can retrieve the decisions based on a policy from a > > component implemented somewhere else. > > The BPF LSM provides mechanism. The eBPF programs provide policy. Yeah, let's stick what we call an LSM in the kernel, Here, "bpf" is the LSM like selinux,apparmor and this is what you set in CONFIG_LSM or pass on cmdline as lsm= and can be seen in /sys/kernel/security/lsm Calling your BPF programs an LSM will just confuse people. > > > > > Hopefully, I understood the basic principles correctly. > > I let the eBPF maintainers comment on this. > > > > Thanks > > > > Roberto > > > > HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 > > Managing Director: Li Peng, Zhong Ronghua > > > >>> What do you think? > >>> > >>> Thanks > >>> > >>> Roberto > >>> > >>> HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 > >>> Managing Director: Li Peng, Zhong Ronghua _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: KP Singh <kpsingh@kernel.org> To: Casey Schaufler <casey@schaufler-ca.com> Cc: Roberto Sassu <roberto.sassu@huawei.com>, Djalal Harouni <tixxdz@gmail.com>, Alexei Starovoitov <alexei.starovoitov@gmail.com>, "corbet@lwn.net" <corbet@lwn.net>, "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>, "ast@kernel.org" <ast@kernel.org>, "daniel@iogearbox.net" <daniel@iogearbox.net>, "andrii@kernel.org" <andrii@kernel.org>, "shuah@kernel.org" <shuah@kernel.org>, "mcoquelin.stm32@gmail.com" <mcoquelin.stm32@gmail.com>, "alexandre.torgue@foss.st.com" <alexandre.torgue@foss.st.com>, "zohar@linux.ibm.com" <zohar@linux.ibm.com>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "bpf@vger.kernel.org" <bpf@vger.kernel.org>, "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>, "linux-stm32@st-md-mailman.stormreply.com" <linux-stm32@st-md-mailman.stormreply.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>, "linux-security-module@vger.kernel.org" <linux-security-module@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 00/18] bpf: Secure and authenticated preloading of eBPF programs Date: Tue, 5 Apr 2022 18:37:42 +0200 [thread overview] Message-ID: <CACYkzJ4KwWykYjb0DJ1SHe9syiefqgfjDB8om7RNx10vZ3UiKg@mail.gmail.com> (raw) In-Reply-To: <fb804242-da2c-4213-9dc3-f09ea42f0355@schaufler-ca.com> On Tue, Apr 5, 2022 at 6:22 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > > On 4/5/2022 8:29 AM, Roberto Sassu wrote: > >> From: Casey Schaufler [mailto:casey@schaufler-ca.com] > >> Sent: Tuesday, April 5, 2022 4:50 PM > >> On 4/4/2022 10:20 AM, Roberto Sassu wrote: > >>>> From: Djalal Harouni [mailto:tixxdz@gmail.com] > >>>> Sent: Monday, April 4, 2022 9:45 AM > >>>> On Sun, Apr 3, 2022 at 5:42 PM KP Singh <kpsingh@kernel.org> wrote: > >>>>> On Sat, Apr 2, 2022 at 1:55 AM Alexei Starovoitov > >>>>> <alexei.starovoitov@gmail.com> wrote: > >>>> ... > >>>>>>> Pinning > >>>>>>> them to unreachable inodes intuitively looked the > >>>>>>> way to go for achieving the stated goal. > >>>>>> We can consider inodes in bpffs that are not unlinkable by root > >>>>>> in the future, but certainly not for this use case. > >>>>> Can this not be already done by adding a BPF_LSM program to the > >>>>> inode_unlink LSM hook? > >>>>> > >>>> Also, beside of the inode_unlink... and out of curiosity: making > >> sysfs/bpffs/ > >>>> readonly after pinning, then using bpf LSM hooks > >>>> sb_mount|remount|unmount... > >>>> family combining bpf() LSM hook... isn't this enough to: > >>>> 1. Restrict who can pin to bpffs without using a full MAC > >>>> 2. Restrict who can delete or unmount bpf filesystem > >>>> > >>>> ? > >>> I'm thinking to implement something like this. > >>> > >>> First, I add a new program flag called > >>> BPF_F_STOP_ONCONFIRM, which causes the ref count > >>> of the link to increase twice at creation time. In this way, > >>> user space cannot make the link disappear, unless a > >>> confirmation is explicitly sent via the bpf() system call. > >>> > >>> Another advantage is that other LSMs can decide > >>> whether or not they allow a program with this flag > >>> (in the bpf security hook). > >>> > >>> This would work regardless of the method used to > >>> load the eBPF program (user space or kernel space). > >>> > >>> Second, I extend the bpf() system call with a new > >>> subcommand, BPF_LINK_CONFIRM_STOP, which > >>> decreasres the ref count for the link of the programs > >>> with the BPF_F_STOP_ONCONFIRM flag. I will also > >>> introduce a new security hook (something like > >>> security_link_confirm_stop), so that an LSM has the > >>> opportunity to deny the stop (the bpf security hook > >>> would not be sufficient to determine exactly for > >>> which link the confirmation is given, an LSM should > >>> be able to deny the stop for its own programs). > >> Would you please stop referring to a set of eBPF programs > >> loaded into the BPF LSM as an LSM? Call it a BPF security > >> module (BSM) if you must use an abbreviation. An LSM is a > >> provider of security_ hooks. In your case that is BPF. When > >> you call the set of eBPF programs an LSM it is like calling > >> an SELinux policy an LSM. > > An eBPF program could be a provider of security_ hooks > > too. > > No, it can't. If I look in /sys/kernel/security/lsm what > you see is "bpf". The LSM is BPF. What BPF does in its > hooks is up to it and its responsibility. > > > The bpf LSM is an aggregator, similarly to your > > infrastructure to manage built-in LSMs. Maybe, calling > > it second-level LSM or secondary LSM would better > > represent this new class. > > It isn't an LSM, and adding a qualifier doesn't make it > one and only adds to the confusion. > > > The only differences are the registration method, (SEC > > directive instead of DEFINE_LSM), and what the hook > > implementation can access. > > Those two things pretty well define what an LSM is. > > > The implementation of a security_ hook via eBPF can > > follow the same structure of built-in LSMs, i.e. it can be > > uniquely responsible for enforcing and be policy-agnostic, > > and can retrieve the decisions based on a policy from a > > component implemented somewhere else. > > The BPF LSM provides mechanism. The eBPF programs provide policy. Yeah, let's stick what we call an LSM in the kernel, Here, "bpf" is the LSM like selinux,apparmor and this is what you set in CONFIG_LSM or pass on cmdline as lsm= and can be seen in /sys/kernel/security/lsm Calling your BPF programs an LSM will just confuse people. > > > > > Hopefully, I understood the basic principles correctly. > > I let the eBPF maintainers comment on this. > > > > Thanks > > > > Roberto > > > > HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 > > Managing Director: Li Peng, Zhong Ronghua > > > >>> What do you think? > >>> > >>> Thanks > >>> > >>> Roberto > >>> > >>> HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 > >>> Managing Director: Li Peng, Zhong Ronghua
next prev parent reply other threads:[~2022-04-05 16:39 UTC|newest] Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-28 17:50 [PATCH 00/18] bpf: Secure and authenticated preloading of eBPF programs Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 01/18] bpf: Export bpf_link_inc() Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 02/18] bpf-preload: Move bpf_preload.h to include/linux Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 03/18] bpf-preload: Generalize object pinning from the kernel Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 04/18] bpf-preload: Export and call bpf_obj_do_pin_kernel() Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 05/18] bpf-preload: Generate static variables Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-29 23:51 ` Andrii Nakryiko 2022-03-29 23:51 ` Andrii Nakryiko 2022-03-30 7:44 ` Roberto Sassu 2022-03-30 7:44 ` Roberto Sassu 2022-04-04 0:22 ` Andrii Nakryiko 2022-04-04 0:22 ` Andrii Nakryiko 2022-03-30 15:12 ` Roberto Sassu 2022-03-30 15:12 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 06/18] bpf-preload: Generate free_objs_and_skel() Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 07/18] bpf-preload: Generate preload() Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 08/18] bpf-preload: Generate load_skel() Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 09/18] bpf-preload: Generate code to pin non-internal maps Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 10/18] bpf-preload: Generate bpf_preload_ops Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 11/18] bpf-preload: Store multiple bpf_preload_ops structures in a linked list Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 12/18] bpf-preload: Implement new registration method for preloading eBPF programs Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 13/18] bpf-preload: Move pinned links and maps to a dedicated directory in bpffs Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 14/18] bpf-preload: Switch to new preload registration method Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-29 2:35 ` kernel test robot 2022-03-29 2:35 ` kernel test robot 2022-03-29 3:27 ` kernel test robot 2022-03-29 3:27 ` kernel test robot 2022-03-28 17:50 ` [PATCH 15/18] bpf-preload: Generate code of kernel module to preload Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 16/18] bpf-preload: Do kernel mount to ensure that pinned objects don't disappear Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-29 2:15 ` kernel test robot 2022-03-29 2:15 ` kernel test robot 2022-03-29 4:08 ` kernel test robot 2022-03-29 4:08 ` kernel test robot 2022-03-28 17:50 ` [PATCH 17/18] bpf-preload/selftests: Add test for automatic generation of preload methods Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 18/18] bpf-preload/selftests: Preload a test eBPF program and check pinned objects Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-29 23:51 ` [PATCH 00/18] bpf: Secure and authenticated preloading of eBPF programs Andrii Nakryiko 2022-03-29 23:51 ` Andrii Nakryiko 2022-03-30 7:21 ` Roberto Sassu 2022-03-30 7:21 ` Roberto Sassu 2022-03-31 2:27 ` Alexei Starovoitov 2022-03-31 2:27 ` Alexei Starovoitov 2022-03-31 8:25 ` Roberto Sassu 2022-03-31 8:25 ` Roberto Sassu 2022-04-01 23:55 ` Alexei Starovoitov 2022-04-01 23:55 ` Alexei Starovoitov 2022-04-02 1:03 ` KP Singh 2022-04-02 1:03 ` KP Singh 2022-04-04 7:44 ` Djalal Harouni 2022-04-04 7:44 ` Djalal Harouni 2022-04-04 17:20 ` Roberto Sassu 2022-04-04 17:20 ` Roberto Sassu 2022-04-04 22:49 ` Alexei Starovoitov 2022-04-04 22:49 ` Alexei Starovoitov 2022-04-05 0:00 ` KP Singh 2022-04-05 0:00 ` KP Singh 2022-04-05 13:11 ` [POC][USER SPACE][PATCH] Introduce LSM to protect pinned objects Roberto Sassu 2022-04-05 13:11 ` Roberto Sassu 2022-04-05 22:47 ` Casey Schaufler 2022-04-05 22:47 ` Casey Schaufler 2022-04-06 6:55 ` Roberto Sassu 2022-04-06 6:55 ` Roberto Sassu 2022-04-05 14:49 ` [PATCH 00/18] bpf: Secure and authenticated preloading of eBPF programs Casey Schaufler 2022-04-05 14:49 ` Casey Schaufler 2022-04-05 15:29 ` Roberto Sassu 2022-04-05 15:29 ` Roberto Sassu 2022-04-05 16:21 ` Casey Schaufler 2022-04-05 16:21 ` Casey Schaufler 2022-04-05 16:37 ` KP Singh [this message] 2022-04-05 16:37 ` KP Singh 2022-04-04 17:41 ` Roberto Sassu 2022-04-04 17:41 ` Roberto Sassu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CACYkzJ4KwWykYjb0DJ1SHe9syiefqgfjDB8om7RNx10vZ3UiKg@mail.gmail.com \ --to=kpsingh@kernel.org \ --cc=alexandre.torgue@foss.st.com \ --cc=alexei.starovoitov@gmail.com \ --cc=andrii@kernel.org \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=casey@schaufler-ca.com \ --cc=corbet@lwn.net \ --cc=daniel@iogearbox.net \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=linux-stm32@st-md-mailman.stormreply.com \ --cc=mcoquelin.stm32@gmail.com \ --cc=netdev@vger.kernel.org \ --cc=roberto.sassu@huawei.com \ --cc=shuah@kernel.org \ --cc=tixxdz@gmail.com \ --cc=viro@zeniv.linux.org.uk \ --cc=zohar@linux.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.