[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#990411: systemd: set kernel.unprivileged_bpf_disabled = 1



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


Reply to: