netdev - Re: [PATCH bpf-next] tools: bpftool: allow unprivileged users to probe features

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

Message-ID: <b84df406-608d-f597-59ba-a27764eb1fcb@isovalent.com>
Date:   Mon, 27 Apr 2020 15:16:47 +0100
From:   Quentin Monnet <quentin@...valent.com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        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

2020-04-27 14:58 UTC+0200 ~ Daniel Borkmann <daniel@...earbox.net>
> 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?

That's a valid concern, I'll rework the patch to add support for the
explicit option on the command line as you suggest. Thanks for the review!

Quentin