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

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

 



2020-04-27 14:58 UTC+0200 ~ Daniel Borkmann <daniel@xxxxxxxxxxxxx>
> 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@xxxxxxxx>
>> Cc: Michael Kerrisk <mtk.manpages@xxxxxxxxx>
>> Signed-off-by: Quentin Monnet <quentin@xxxxxxxxxxxxx>
>> ---
>>   .../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



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux