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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 26 May 2020 00:20:44 +0200
From:   Daniel Borkmann <>
To:     Quentin Monnet <>,
        Alexei Starovoitov <>
        Andrii Nakryiko <>
Subject: Re: [PATCH bpf-next v2] tools: bpftool: make capability check account
 for new BPF caps

On 5/23/20 3:02 AM, Quentin Monnet wrote:
> Following the introduction of CAP_BPF, and the switch from CAP_SYS_ADMIN
> to other capabilities for various BPF features, update the capability
> checks (and potentially, drops) in bpftool for feature probes. Because
> bpftool and/or the system might not know of CAP_BPF yet, some caution is
> necessary:
> - If compiled and run on a system with CAP_BPF, check CAP_BPF,
> - Guard against CAP_BPF being undefined, to allow compiling bpftool from
>    latest sources on older systems. If the system where feature probes
>    are run does not know of CAP_BPF, stop checking after CAP_SYS_ADMIN,
>    as this should be the only capability required for all the BPF
>    probing.
> - If compiled from latest sources on a system without CAP_BPF, but later
>    executed on a newer system with CAP_BPF knowledge, then we only test
>    CAP_SYS_ADMIN. Some probes may fail if the bpftool process has
>    CAP_SYS_ADMIN but misses the other capabilities. The alternative would
>    be to redefine the value for CAP_BPF in bpftool, but this does not
>    look clean, and the case sounds relatively rare anyway.
> Note that libcap offers a cap_to_name() function to retrieve the name of
> a given capability (e.g. "cap_sys_admin"). We do not use it because
> deriving the names from the macros looks simpler than using
> cap_to_name() (doing a strdup() on the string) + cap_free() + handling
> the case of failed allocations, when we just want to use the name of the
> capability in an error message.
> The checks when compiling without libcap (i.e. root versus non-root) are
> unchanged.
> v2:
> - Do not allocate cap_list dynamically.
> - Drop BPF-related capabilities when running with "unprivileged", even
>    if we didn't have the full set in the first place (in v1, we would
>    skip dropping them in that case).
> - Keep track of what capabilities we have, print the names of the
>    missing ones for privileged probing.
> - Attempt to drop only the capabilities we actually have.
> - Rename a couple variables.
> Signed-off-by: Quentin Monnet <>

Applied, thanks!

Powered by blists - more mailing lists