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.