linux-kernel - Re: [PATCH bpf-next 1/2] bpf: Add struct bpf_token

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: <CAEf4BzbwRj7XC0rvWDzJX+v3QweYBh=dT6H17piyD=v1QLbi7w@mail.gmail.com>
Date: Mon, 14 Jul 2025 14:06:49 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Tao Chen <chen.dylane@...ux.dev>
Cc: ast@...nel.org, daniel@...earbox.net, andrii@...nel.org, 
	martin.lau@...ux.dev, eddyz87@...il.com, song@...nel.org, 
	yonghong.song@...ux.dev, john.fastabend@...il.com, kpsingh@...nel.org, 
	sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org, willemb@...gle.com, 
	kerneljasonxing@...il.com, bpf@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info

On Mon, Jul 14, 2025 at 6:16 AM Tao Chen <chen.dylane@...ux.dev> wrote:
>
> 在 2025/7/12 01:10, Andrii Nakryiko 写道:
>
> Hi Andrri,
>
> > On Fri, Jul 11, 2025 at 2:45 AM Tao Chen <chen.dylane@...ux.dev> wrote:
> >>
> >> The 'commit 35f96de04127 ("bpf: Introduce BPF token object")' added
> >> BPF token as a new kind of BPF kernel object. And BPF_OBJ_GET_INFO_BY_FD
> >> already used to get BPF object info, so we can also get token info with
> >> this cmd.
> >>
> >
> > Do you have a specific use case in mind for this API? I can see how
> > this might be useful for some hypothetical cases, but I have a few
> > reservations as of right now:
> >
> >    - we don't allow iterating all BPF token objects in the system the
> > same way we do it for progs, maps, and btfs, so bpftool cannot take
> > advantage of this to list all available tokens and their info, which
> > makes this API a bit less useful, IMO;
> >
> >    - BPF token was designed in a way that users don't really need to
> > know allowed_* values (and if they do, they can get it from BPF FS's
> > mount information (e.g., from /proc/mounts).
> >
> > As I said, I can come up with some hypothetical situations where a
> > user might want to avoid doing something that otherwise they'd do
> > outside of userns, but I'm wondering what your motivations are for
> > this?
> >
>
> Sorry for the delay. Recentlly, i tried to use bpf_token feature in our
> production environment, in fact, bpf_token grants permission to prog,
> map, cmd, etc. It would be great if it could indicate which specific
> permission is the issue to user. So i wanted to provide a token info
> query interface. As you said, "mount | grep bpf" may solve it, but
> functionally, can we make it more complete?

I wanted to understand what you need this for. So your case is on
failure to report what BPF token is allowing, so it's easier to debug
what's missing, is that right? I think it makes sense overall, so I
don't really have objections to adding the API.

>
> >> Signed-off-by: Tao Chen <chen.dylane@...ux.dev>
> >> ---
> >>   include/linux/bpf.h            | 11 +++++++++++
> >>   include/uapi/linux/bpf.h       |  8 ++++++++
> >>   kernel/bpf/syscall.c           | 18 ++++++++++++++++++
> >>   kernel/bpf/token.c             | 30 ++++++++++++++++++++++++++++--
> >>   tools/include/uapi/linux/bpf.h |  8 ++++++++
> >>   5 files changed, 73 insertions(+), 2 deletions(-)
> >>
> >
> > [...]
>
>
> --
> Best Regards
> Tao Chen