linux-kernel - Re: [RFC PATCH bpf-next 2/7] bpf: Add enum bpf

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] [day] [month] [year] [list]

Message-ID: <CAPhsuW5duwV_OErkW-DbuwAkDX-X1KFMnqoFobn2f+VOtbPkTg@mail.gmail.com>
Date: Tue, 21 Jan 2025 09:41:12 -0800
From: Song Liu <song@...nel.org>
To: Juntong Deng <juntong.deng@...look.com>
Cc: andrii@...nel.org, ast@...nel.org, daniel@...earbox.net, 
	john.fastabend@...il.com, martin.lau@...ux.dev, eddyz87@...il.com, 
	yonghong.song@...ux.dev, kpsingh@...nel.org, sdf@...ichev.me, 
	haoluo@...gle.com, jolsa@...nel.org, memxor@...il.com, tj@...nel.org, 
	void@...ifault.com, bpf@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH bpf-next 2/7] bpf: Add enum bpf_capability

On Mon, Jan 20, 2025 at 1:50 PM Juntong Deng <juntong.deng@...look.com> wrote:
>
[...]
>
> >>
> >> Would it be a better idea for us to let each kfunc have its own
> >> capability attribute?
> >
> > This is no different to the BPF helper function ID, which turned
> > out to be not scalable.
> >
>
> There still seems to be a difference? BPF capabilities are not
> one-to-one with kfuncs, and multiple kfuncs can be bound to one
> BPF capability.
>
> BPF capabilities are more like fine-grained versions of program types.

I personally think struct_ops gives good enough fine-grained control.
Therefore, I don't see a real need for a different concept.

[...]

> >>
> >> For example, if a system administrator wants to open the features of the
> >> HID-BPF driver to users, but the system administrator does not want to
> >> open other BPF features to users, such as sched_ext.
> >
> > This appears to be a totally separate topic.
> >
>
> Although I am not sure, I guess general fine-grained permissions
> management might still be valuable (not necessarily BPF capabilities).
>
> I found that Andrii Nakryiko implemented something similar in
> BPF Token[0].
>
> Similar to SCX, BPF features are fine-grained through masks to restrict
> only part of the BPF features to be opened.
>
> This seems to indicate that the demand for making BPF permissions
> management fine-grained has always existed, and the demand for opening
> only part of the BPF features will reappear in different forms.
>
> Maybe we do need a general fine-grained permissions management solution?

I don't think it is easy to build a fine-grained permission management
solution that fits most scenarios. It is better to do this via programmable
interfaces, e.g. with BPF LSM.

Thanks,
Song

> If Andrii saw this email, could you please join the discussion?
>
> [0]: https://lwn.net/Articles/947173/
>