netdev - Re: [PATCH bpf-next 6/7] bpf: enable retrival of pid/tgid/comm from bpf cgroup hooks

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

Date:   Fri, 27 Mar 2020 17:49:29 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Martynas Pumputis <m@...bda.lt>,
        Joe Stringer <joe@...d.net.nz>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>
Subject: Re: [PATCH bpf-next 6/7] bpf: enable retrival of pid/tgid/comm from
 bpf cgroup hooks

On Fri, Mar 27, 2020 at 8:59 AM Daniel Borkmann <daniel@...earbox.net> wrote:
>
> We already have the bpf_get_current_uid_gid() helper enabled, and
> given we now have perf event RB output available for connect(),
> sendmsg(), recvmsg() and bind-related hooks, add a trivial change
> to enable bpf_get_current_pid_tgid() and bpf_get_current_comm()
> as well.
>
> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>
> ---

LGTM, there was probably never a good reason this wasn't available
from the very beginning :)

Might as well add bpf_get_current_uid_gid() if it's not there yet.

Acked-by: Andrii Nakryiko <andriin@...com>

>  net/core/filter.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 5cec3ac9e3dd..bb4a196c8809 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -6018,6 +6018,10 @@ sock_filter_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
>                 return &bpf_get_netns_cookie_sock_proto;
>         case BPF_FUNC_perf_event_output:
>                 return &bpf_event_output_data_proto;
> +       case BPF_FUNC_get_current_pid_tgid:
> +               return &bpf_get_current_pid_tgid_proto;
> +       case BPF_FUNC_get_current_comm:
> +               return &bpf_get_current_comm_proto;

So you are not adding it to bpf_base_func_proto() instead, because
that one can be used in BPF programs that don't have a valid current,
is that right? If yes, would it make sense to have a common
bpf_base_process_ctx_func_proto() function for cases where there is a
valid current and add all the functions there (including uid_gid and
whatever else makes sense?)

>  #ifdef CONFIG_CGROUPS
>         case BPF_FUNC_get_current_cgroup_id:
>                 return &bpf_get_current_cgroup_id_proto;
> @@ -6058,6 +6062,10 @@ sock_addr_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
>                 return &bpf_get_local_storage_proto;
>         case BPF_FUNC_perf_event_output:
>                 return &bpf_event_output_data_proto;
> +       case BPF_FUNC_get_current_pid_tgid:
> +               return &bpf_get_current_pid_tgid_proto;
> +       case BPF_FUNC_get_current_comm:
> +               return &bpf_get_current_comm_proto;
>  #ifdef CONFIG_CGROUPS
>         case BPF_FUNC_get_current_cgroup_id:
>                 return &bpf_get_current_cgroup_id_proto;
> --
> 2.21.0
>