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
| ||
|
Date: Mon, 8 Aug 2022 14:14:33 +0200 From: Kumar Kartikeya Dwivedi <memxor@...il.com> To: Artem Savkov <asavkov@...hat.com> Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, bpf@...r.kernel.org, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Andrea Arcangeli <aarcange@...hat.com>, Daniel Vacek <dvacek@...hat.com>, Jiri Olsa <olsajiri@...il.com>, Song Liu <song@...nel.org>, Daniel Xu <dxu@...uu.xyz> Subject: Re: [PATCH bpf-next v3 1/3] bpf: add destructive kfunc flag On Mon, 8 Aug 2022 at 11:48, Artem Savkov <asavkov@...hat.com> wrote: > > Add KF_DESTRUCTIVE flag for destructive functions. Functions with this > flag set will require CAP_SYS_BOOT capabilities. > > Signed-off-by: Artem Savkov <asavkov@...hat.com> > --- > include/linux/btf.h | 1 + > kernel/bpf/verifier.c | 5 +++++ > 2 files changed, 6 insertions(+) > > diff --git a/include/linux/btf.h b/include/linux/btf.h > index cdb376d53238..51a0961c84e3 100644 > --- a/include/linux/btf.h > +++ b/include/linux/btf.h > @@ -49,6 +49,7 @@ > * for this case. > */ > #define KF_TRUSTED_ARGS (1 << 4) /* kfunc only takes trusted pointer arguments */ > +#define KF_DESTRUCTIVE (1 << 5) /* kfunc performs destructive actions */ > Please also document this flag in Documentation/bpf/kfuncs.rst. And maybe instead of KF_DESTRUCTIVE, it might be more apt to call this KF_CAP_SYS_BOOT. While it is true you had a destructive flag for programs being loaded earlier, so there was a mapping between the two UAPI and kfunc flags, what it has boiled down to is that this flag just requires CAP_SYS_BOOT (in addition to other capabilities) during load. So that name might express the intent a bit better. We might soon have similar flags encoding requirements of other capabilities on load. The flag rename is just a suggestion, up to you. > struct btf; > struct btf_member; > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index 096fdac70165..e52ca1631d3f 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -7584,6 +7584,11 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn, > func_name); > return -EACCES; > } > + if (*kfunc_flags & KF_DESTRUCTIVE && !capable(CAP_SYS_BOOT)) { > + verbose(env, "destructive kfunc calls require CAP_SYS_BOOT capabilities\n"); > + return -EACCES; > + } > + > acq = *kfunc_flags & KF_ACQUIRE; > > /* Check the arguments */ > -- > 2.37.1 >
Powered by blists - more mailing lists