linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roberto Sassu <roberto.sassu@huawei.com>
To: <corbet@lwn.net>, <viro@zeniv.linux.org.uk>, <ast@kernel.org>,
	<daniel@iogearbox.net>, <andrii@kernel.org>, <kpsingh@kernel.org>,
	<shuah@kernel.org>, <mcoquelin.stm32@gmail.com>,
	<alexandre.torgue@foss.st.com>, <zohar@linux.ibm.com>
Cc: <linux-doc@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
	<netdev@vger.kernel.org>, <bpf@vger.kernel.org>,
	<linux-kselftest@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-integrity@vger.kernel.org>,
	<linux-security-module@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	Roberto Sassu <roberto.sassu@huawei.com>
Subject: [PATCH 16/18] bpf-preload: Do kernel mount to ensure that pinned objects don't disappear
Date: Mon, 28 Mar 2022 19:50:31 +0200	[thread overview]
Message-ID: <20220328175033.2437312-17-roberto.sassu@huawei.com> (raw)
In-Reply-To: <20220328175033.2437312-1-roberto.sassu@huawei.com>

One of the differences between traditional LSMs in the security subsystem
and LSMs implemented as eBPF programs is that for the latter category it
cannot be guaranteed that they cannot be stopped.

If a pinned program is unpinned, its execution will be stopped and will not
enforce anymore its policy. For traditional LSMs this problem does not
arise as, once they are invoked by the kernel, only the LSMs themselves
decide whether or not they could be stopped.

Solve this problem by mounting the bpf filesystem from the kernel, so that
an object cannot be unpinned (a kernel mount is not accessible to user
space). This will ensure that the LSM will run until the very end of the
kernel lifecycle.

Delay the kernel mount until the security subsystem (e.g. IMA) is fully
initialized (e.g. keys loaded), so that the security subsystem can evaluate
kernel modules loaded by populate_bpffs().

Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
---
 fs/namespace.c      | 1 +
 include/linux/bpf.h | 5 +++++
 init/main.c         | 2 ++
 kernel/bpf/inode.c  | 9 +++++++++
 4 files changed, 17 insertions(+)

diff --git a/fs/namespace.c b/fs/namespace.c
index 6e9844b8c6fb..3b69f96dc641 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -31,6 +31,7 @@
 #include <uapi/linux/mount.h>
 #include <linux/fs_context.h>
 #include <linux/shmem_fs.h>
+#include <linux/bpf.h>
 #include <linux/mnt_idmapping.h>
 
 #include "pnode.h"
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index bdb5298735ce..5f624310fda2 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -1103,6 +1103,8 @@ static inline void bpf_module_put(const void *data, struct module *owner)
 		module_put(owner);
 }
 
+void __init mount_bpffs(void);
+
 #ifdef CONFIG_NET
 /* Define it here to avoid the use of forward declaration */
 struct bpf_dummy_ops_state {
@@ -1141,6 +1143,9 @@ static inline int bpf_struct_ops_map_sys_lookup_elem(struct bpf_map *map,
 {
 	return -EINVAL;
 }
+static inline void __init mount_bpffs(void)
+{
+}
 #endif
 
 struct bpf_array {
diff --git a/init/main.c b/init/main.c
index 0c064c2c79fd..30dcd0dd9faa 100644
--- a/init/main.c
+++ b/init/main.c
@@ -99,6 +99,7 @@
 #include <linux/kcsan.h>
 #include <linux/init_syscalls.h>
 #include <linux/stackdepot.h>
+#include <linux/bpf.h>
 #include <net/net_namespace.h>
 
 #include <asm/io.h>
@@ -1638,4 +1639,5 @@ static noinline void __init kernel_init_freeable(void)
 	 */
 
 	integrity_load_keys();
+	mount_bpffs();
 }
diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c
index c1941c65ce95..e8361d7679d0 100644
--- a/kernel/bpf/inode.c
+++ b/kernel/bpf/inode.c
@@ -1020,3 +1020,12 @@ static int __init bpf_init(void)
 	return ret;
 }
 fs_initcall(bpf_init);
+
+static struct vfsmount *bpffs_mount __read_mostly;
+
+void __init mount_bpffs(void)
+{
+	bpffs_mount = kern_mount(&bpf_fs_type);
+	if (IS_ERR(bpffs_mount))
+		pr_err("bpffs: could not mount!\n");
+}
-- 
2.32.0


  parent reply	other threads:[~2022-03-28 17:55 UTC|newest]

Thread overview: 45+ 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 ` [PATCH 01/18] bpf: Export bpf_link_inc() 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 ` [PATCH 03/18] bpf-preload: Generalize object pinning from the kernel 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 ` [PATCH 05/18] bpf-preload: Generate static variables Roberto Sassu
2022-03-29 23:51   ` Andrii Nakryiko
2022-03-30  7:44     ` Roberto Sassu
2022-04-04  0:22       ` Andrii Nakryiko
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 ` [PATCH 07/18] bpf-preload: Generate preload() Roberto Sassu
2022-03-28 17:50 ` [PATCH 08/18] bpf-preload: Generate load_skel() 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 ` [PATCH 10/18] bpf-preload: Generate bpf_preload_ops 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 ` [PATCH 12/18] bpf-preload: Implement new registration method for preloading eBPF programs 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 ` [PATCH 14/18] bpf-preload: Switch to new preload registration method Roberto Sassu
2022-03-29  2:35   ` 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 [this message]
2022-03-29  2:15   ` [PATCH 16/18] bpf-preload: Do kernel mount to ensure that pinned objects don't disappear 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 ` [PATCH 18/18] bpf-preload/selftests: Preload a test eBPF program and check pinned objects Roberto Sassu
2022-03-29 23:51 ` [PATCH 00/18] bpf: Secure and authenticated preloading of eBPF programs Andrii Nakryiko
2022-03-30  7:21   ` Roberto Sassu
2022-03-31  2:27 ` Alexei Starovoitov
2022-03-31  8:25   ` Roberto Sassu
2022-04-01 23:55     ` Alexei Starovoitov
2022-04-02  1:03       ` KP Singh
2022-04-04  7:44         ` Djalal Harouni
2022-04-04 17:20           ` Roberto Sassu
2022-04-04 22:49             ` Alexei Starovoitov
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 22:47                   ` Casey Schaufler
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 15:29               ` Roberto Sassu
2022-04-05 16:21                 ` Casey Schaufler
2022-04-05 16:37                   ` KP Singh
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=20220328175033.2437312-17-roberto.sassu@huawei.com \
    --to=roberto.sassu@huawei.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=kpsingh@kernel.org \
    --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=shuah@kernel.org \
    --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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).