On Mon, Aug 02, 2021 at 09:16:51PM +0200, Ben Hutchings wrote:
> Control: tag -1 patch
>
> I think disabling unprivileged BPF is probably sensible. So far as I
> know, it is quite limited in usefulness (without exploiting verifier
> bugs :-). If it can't be enabled again, this should maybe be done with
> a sysctl config file in linux-base rather than being a built-in default
> that can never be overridden.
>
> But I don't see *why* it shouldn't be possible to enable again. That
> makes sense for e.g. kernel.modules_disabled where it's a way for root
> to drop privileges, but root always retains the ability to use BPF.
>
> This (untested) patch should fix the default while allowing it to be
> changed back:
>
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -50,7 +50,7 @@ static DEFINE_SPINLOCK(map_idr_lock);
> static DEFINE_IDR(link_idr);
> static DEFINE_SPINLOCK(link_idr_lock);
>
> -int sysctl_unprivileged_bpf_disabled __read_mostly;
> +int sysctl_unprivileged_bpf_disabled __read_mostly = 1;
>
> static const struct bpf_map_ops * const bpf_map_types[] = {
> #define BPF_PROG_TYPE(_id, _name, prog_ctx_type, kern_ctx_type)
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -2639,9 +2639,8 @@ static struct ctl_table kern_table[] = {
> .data = &sysctl_unprivileged_bpf_disabled,
> .maxlen = sizeof(sysctl_unprivileged_bpf_disabled),
> .mode = 0644,
> - /* only handle a transition from default "0" to "1" */
> .proc_handler = proc_dointvec_minmax,
> - .extra1 = SYSCTL_ONE,
> + .extra1 = SYSCTL_ZERO,
> .extra2 = SYSCTL_ONE,
> },
> {
> --- END ---
Good news are, that in upstream in 5.13-rc4 08389d888287 ("bpf: Add
kconfig knob for disabling unpriv bpf by default") was added[1],
exaclty allowing to turn it off by default, but without making it
"irreversible".
[1] https://git.kernel.org/linus/08389d888287c3823f80b0216766b71e17f0aba5
I have currently a set of bpf fixes pending in
https://salsa.debian.org/kernel-team/linux/-/merge_requests/380 which
we hopefully can get in for bullseye still?
Regards,
Salvatore
