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.
