Thread (36 messages) 36 messages, 7 authors, 2022-07-01

Re: [PATCH v5 bpf-next 4/5] bpf: Add a bpf_getxattr kfunc

From: Christian Brauner <brauner@kernel.org>
Date: 2022-06-28 17:23:19
Also in: bpf, linux-fsdevel

On Tue, Jun 28, 2022 at 04:19:47PM +0000, KP Singh wrote:
quoted hunk ↗ jump to hunk
LSMs like SELinux store security state in xattrs. bpf_getxattr enables
BPF LSM to implement similar functionality. In combination with
bpf_local_storage, xattrs can be used to develop more complex security
policies.

This kfunc wraps around __vfs_getxattr which can sleep and is,
therefore, limited to sleepable programs using the newly added
sleepable_set for kfuncs.

Signed-off-by: KP Singh <kpsingh@kernel.org>
---
 kernel/trace/bpf_trace.c | 42 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 4be976cf7d63..87496d57b099 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -20,6 +20,7 @@
 #include <linux/fprobe.h>
 #include <linux/bsearch.h>
 #include <linux/sort.h>
+#include <linux/xattr.h>
 
 #include <net/bpf_sk_storage.h>
 
@@ -1181,6 +1182,47 @@ static const struct bpf_func_proto bpf_get_func_arg_cnt_proto = {
 	.arg1_type	= ARG_PTR_TO_CTX,
 };
 
+__diag_push();
+__diag_ignore_all("-Wmissing-prototypes",
+		  "kfuncs that are used in tracing/LSM BPF programs");
+
+ssize_t bpf_getxattr(struct dentry *dentry, struct inode *inode,
+		     const char *name, void *value, int value__sz)
+{
+	return __vfs_getxattr(dentry, inode, name, value, value__sz);
So this might all be due to my ignorance where and how this is supposed
to be used but using __vfs_getxattr() is performing _zero_ permission
checks. That means every eBPF program will be able to retrieve whatever
extended attribute it likes.

In addition to generic permission checking your code also assumes that
every caller is located in the initial user namespace. Is that a valid
assumption?

POSIX ACLs can store additional [u,g]ids on disk that need to be
translated according to the caller's user namespace.

Looking at your selftest example you have a current task and you also
have access to a struct file which makes me doubt that this assumption
is correct. But I'm happy to be convinced otherwise.

Also, if the current task is retrieving extended attributes from an
idmapped mount you also need to take the mount's idmapping into account.
Otherwise again, you'll retrieve misleading [g,u]id values...

Could you explain to me why that is safe and how this is going to be
used, please? As it stands I can't make heads nor tails of this.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help