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

Message-ID:
 <AM6PR03MB508002DCA7DBE7C7712ECC30991B2@AM6PR03MB5080.eurprd03.prod.outlook.com>
Date: Fri, 17 Jan 2025 19:37:29 +0000
From: Juntong Deng <juntong.deng@...look.com>
To: Song Liu <song@...nel.org>
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 2025/1/16 22:56, Song Liu wrote:
> On Thu, Jan 16, 2025 at 11:43 AM Juntong Deng <juntong.deng@...look.com> wrote:
>>
>> This patch adds enum bpf_capability, currently only for proof
>> of concept.
>>
>> Signed-off-by: Juntong Deng <juntong.deng@...look.com>
>> ---
>>   include/uapi/linux/bpf.h | 15 +++++++++++++++
>>   1 file changed, 15 insertions(+)
>>
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index 2acf9b336371..94c21d4eb786 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -1058,6 +1058,21 @@ enum bpf_prog_type {
>>          __MAX_BPF_PROG_TYPE
>>   };
>>
>> +enum bpf_capability {
>> +       BPF_CAP_NONE = 0,
>> +       BPF_CAP_TEST_1,
>> +       BPF_CAP_TEST_2,
>> +       BPF_CAP_TEST_3,
>> +       BPF_CAP_SCX_ANY,
>> +       BPF_CAP_SCX_KF_UNLOCKED,
>> +       BPF_CAP_SCX_KF_CPU_RELEASE,
>> +       BPF_CAP_SCX_KF_DISPATCH,
>> +       BPF_CAP_SCX_KF_ENQUEUE,
>> +       BPF_CAP_SCX_KF_SELECT_CPU,
>> +       BPF_CAP_SCX_KF_REST,
>> +       __MAX_BPF_CAP
>> +};
>> +
> 
> I don't think we need to handle these in the core verifier.
> Instead, we can put the same logic in:
> 
>      fetch_kfunc_meta =>
>         btf_kfunc_id_set_contains =>
>             __btf_kfunc_id_set_contains =>
>                hook_filter->filters[i]()
> 
> Thanks,
> Song
> 

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.

Would it be a better idea for us to let each kfunc have its own
capability attribute?

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.

But both HID-BPF and sched_ext are using BPF_PROG_TYPE_STRUCT_OPS, so we
cannot restrict based on program type.

If based on BPF capabilities, maybe the system administrator can give
the user CAP_BPF (Linux capabilities) and set only BPF_CAP_HID
(BPF capabilities) to be enabled in /sys/bpf/bpf_enabled_capabilities
(which can only be modified by CAP_SYS_ADMIN), then the restriction of
only allowing the use of HID-BPF can be applied.

In this example, CAP_BPF is also too coarse-grained. Although BPF
looks like a separate subsystem, in fact BPF (low-level) is
the infrastructure, and we implement features (high-level) for
different scenarios based on BPF. It might be better to manage
BPF at a finer granularity.

If we want to restrict some features and open only some features,
coarse-grained permission management cannot do it.

Maybe BPF capabilities not only can be used to solve the current SCX
context problem, but other problems as well?

Maybe we can have more discussion?

Many thanks.

>>   enum bpf_attach_type {
>>          BPF_CGROUP_INET_INGRESS,
>>          BPF_CGROUP_INET_EGRESS,
>> --
>> 2.39.5
>>