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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 27 Apr 2020 14:58:33 +0200 From: Daniel Borkmann <daniel@...earbox.net> To: Quentin Monnet <quentin@...valent.com>, Alexei Starovoitov <ast@...nel.org> Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, Richard Palethorpe <rpalethorpe@...e.com>, Michael Kerrisk <mtk.manpages@...il.com> Subject: Re: [PATCH bpf-next] tools: bpftool: allow unprivileged users to probe features On 4/23/20 6:04 PM, Quentin Monnet wrote: > There is demand for a way to identify what BPF helper functions are > available to unprivileged users. To do so, allow unprivileged users to > run "bpftool feature probe" to list BPF-related features. This will only > show features accessible to those users, and may not reflect the full > list of features available (to administrators) on the system. For > non-JSON output, print an informational message stating so at the top of > the list. > > Note that there is no particular reason why the probes were restricted > to root, other than the fact I did not need them for unprivileged and > did not bother with the additional checks at the time probes were added. > > Cc: Richard Palethorpe <rpalethorpe@...e.com> > Cc: Michael Kerrisk <mtk.manpages@...il.com> > Signed-off-by: Quentin Monnet <quentin@...valent.com> > --- > .../bpftool/Documentation/bpftool-feature.rst | 4 +++ > tools/bpf/bpftool/feature.c | 32 +++++++++++++------ > 2 files changed, 26 insertions(+), 10 deletions(-) > > diff --git a/tools/bpf/bpftool/Documentation/bpftool-feature.rst b/tools/bpf/bpftool/Documentation/bpftool-feature.rst > index b04156cfd7a3..313888e87249 100644 > --- a/tools/bpf/bpftool/Documentation/bpftool-feature.rst > +++ b/tools/bpf/bpftool/Documentation/bpftool-feature.rst > @@ -49,6 +49,10 @@ DESCRIPTION > Keyword **kernel** can be omitted. If no probe target is > specified, probing the kernel is the default behaviour. > > + Running this command as an unprivileged user will dump only > + the features available to the user, which usually represent a > + small subset of the parameters supported by the system. > + Looks good. I wonder whether the unprivileged should be gated behind an explicit subcommand e.g. `--unprivileged`. My main worry is that if there's a misconfiguration the emitted macro/ header file will suddenly contain a lot less defines and it might go unnoticed if some optimizations in the BPF code are then compiled out by accident. Maybe it would make sense to have a feature test for libcap and then also allow for root to check on features for unpriv this way? > **bpftool feature probe dev** *NAME* [**full**] [**macros** [**prefix** *PREFIX*]] > Probe network device for supported eBPF features and dump > results to the console. > diff --git a/tools/bpf/bpftool/feature.c b/tools/bpf/bpftool/feature.c > index 88718ee6a438..f455bc5fcc64 100644 > --- a/tools/bpf/bpftool/feature.c > +++ b/tools/bpf/bpftool/feature.c > @@ -471,6 +471,11 @@ probe_prog_type(enum bpf_prog_type prog_type, bool *supported_types, > } > > res = bpf_probe_prog_type(prog_type, ifindex); > + /* Probe may succeed even if program load fails, for unprivileged users > + * check that we did not fail because of insufficient permissions > + */ > + if (geteuid() && errno == EPERM) > + res = false; > > supported_types[prog_type] |= res; >
Powered by blists - more mailing lists