On Tue, Jun 28, 2022 at 04:19:47PM +0000, KP Singh wrote: > 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@xxxxxxxxxx> > --- > 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.