linux-kernel - Re: [PATCH bpf-next 2/2] selftests/bpf: Add tests for bpf_get_dentry

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240730-unwahr-tannenwald-ee6157a063a4@brauner>
Date: Tue, 30 Jul 2024 10:59:04 +0200
From: Christian Brauner <brauner@...nel.org>
To: Song Liu <songliubraving@...a.com>
Cc: Song Liu <song@...nel.org>, bpf <bpf@...r.kernel.org>, 
	Linux-Fsdevel <linux-fsdevel@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	Kernel Team <kernel-team@...a.com>, "andrii@...nel.org" <andrii@...nel.org>, 
	"eddyz87@...il.com" <eddyz87@...il.com>, "ast@...nel.org" <ast@...nel.org>, 
	"daniel@...earbox.net" <daniel@...earbox.net>, "martin.lau@...ux.dev" <martin.lau@...ux.dev>, 
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>, "jack@...e.cz" <jack@...e.cz>, 
	"kpsingh@...nel.org" <kpsingh@...nel.org>, "mattbobrowski@...gle.com" <mattbobrowski@...gle.com>
Subject: Re: [PATCH bpf-next 2/2] selftests/bpf: Add tests for
 bpf_get_dentry_xattr

On Tue, Jul 30, 2024 at 05:58:31AM GMT, Song Liu wrote:
> Hi Christian, 
> 
> Thanks a lot for your detailed explanation! We will revisit the design 
> based on these comments and suggestions. 
> 
> One more question about a potential new kfunc bpf_get_inode_xattr(): 
> Should it take dentry as input? IOW, should it look like:
> 
> __bpf_kfunc int bpf_get_inode_xattr(struct dentry *dentry, const char *name__str,
>                                     struct bpf_dynptr *value_p)
> {
>         struct bpf_dynptr_kern *value_ptr = (struct bpf_dynptr_kern *)value_p;
>         u32 value_len;
>         void *value;
>         int ret;
> 
>         if (strncmp(name__str, XATTR_USER_PREFIX, XATTR_USER_PREFIX_LEN))
>                 return -EPERM;
> 
>         value_len = __bpf_dynptr_size(value_ptr);
>         value = __bpf_dynptr_data_rw(value_ptr, value_len);
>         if (!value)
>                 return -EINVAL;
> 
>         ret = inode_permission(&nop_mnt_idmap, inode, MAY_READ);
>         if (ret)
>                 return ret;
>         return __vfs_getxattr(dentry, inode, name__str, value, value_len);
> }
> 
> 
> I am asking because many security_inode_* hooks actually taking dentry as 
> argument. So it makes sense to use dentry for kfuncs. Maybe we should

Some filesystems (i) require access to the @dentry in their xattr
handlers (e.g. 9p) and (ii) ->get() and ->set() xattr handlers can be
called when @inode hasn't been attached to @dentry yet.

So if you allowed to call bpf_get_*_xattr() from
security_d_instantiate() to somehow retrieve xattrs from there, then you
need to pass @dentry and @inode separately and you cannot use
@dentry->d_inode because it would still be NULL.

However, I doubt you'd call bpf_get_*_xattr() from
security_d_instantiate() so imo just pass the dentry and add a check
like:

struct inode *inode = d_inode(dentry);
if (WARN_ON(!inode))
	return -EINVAL;

in there.