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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bbde573f-edd8-0d39-556e-98842e0328f7@iogearbox.net>
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;
>