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: <CAPhsuW4sd5LgmPjceFqaLGu20N4EVxRB_-FWOm5vcCGcRPa3ZA@mail.gmail.com>
Date: Fri, 17 Jan 2025 13:40:33 -0800
From: Song Liu <song@...nel.org>
To: Juntong Deng <juntong.deng@...look.com>
Cc: ast@...nel.org, daniel@...earbox.net, john.fastabend@...il.com, 
	andrii@...nel.org, 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 Fri, Jan 17, 2025 at 11:37 AM Juntong Deng <juntong.deng@...look.com> wrote:
>
[...]
>
> Thanks for your reply.
>
> I am not sure if BPF capabilities is a good approach.
>
> But we currently need filters because we register all kfuncs to program
> types, which are too coarse-grained, so we need additional filters for
> further filtering (make the granularity finer).
>
> We added struct btf_kfunc_hook_filter and added filter logic in
> btf_populate_kfunc_set, __btf_kfunc_id_set_contains, essentially to
> mitigate the problem of coarse-grained permissions management.
>
> If we register all kfuncs to BPF capabilities, then we will no longer
> need additional filters for further filtering because BPF capabilities
> is already fine-grained.

bpf_capabilities_adjust is the filter function with a different name.
So the extra capability concept doesn't give us much benefit.

>
> 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.

>
> In addition, BPF capabilities seem like a extensible idea. Would it be
> valuable if we make other features of BPF (BPF helpers, BPF maps, even
> attach targets) have their own capability attributes and can be managed
> uniformly through BPF capabilities?
>
> For example, if a bpf program has BPF_CAP_TRACING, then it will be able
> to use kprobes and can use tracing related kfuncs and helpers. If a bpf
> program has BPF_CAP_SOCK then it will be able to use
> BPF_MAP_TYPE_SOCKMAP and use socket related kfuncs and helpers.
>
> In other words, if we add a general internal permissions management
> system to the BPF subsystem, would it be valuable?
>
> BPF is general, and it is foreseeable that BPF will be applied to more
> and more subsystems and scenarios, so maybe a general fine-grained
> permissions management would be better?
>
> Fine-grained permissions management will bring potential flexibility
> in configurability.
>
> 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.

[...]

> Maybe we can have more discussion?

We sure need more discussion before shipping any changes for this
topic.

Thanks,
Song