netdev - Re: [PATCH] bpf:add function

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: <Yp9xrkeqUEWvZm9x@kroah.com>
Date:   Tue, 7 Jun 2022 17:41:34 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     山竹小 <mangosteen728@...il.com>
Cc:     ast <ast@...nel.org>, daniel <daniel@...earbox.net>,
        andrii <andrii@...nel.org>, bpf <bpf@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] bpf:add function

On Tue, Jun 07, 2022 at 09:28:58PM +0800, 山竹小 wrote:
> Add the absolute path to get the executable corresponding tothe task
> 
> Signed-off-by: mangosteen728 < mangosteen728@...il.com>
> ---
> Hi
> This is my first attempt to submit patch, there are shortcomings
> please more but wait.
> 
> In security audit often need to get the absolute path to the
> executable of the process so I tried to add bpf_get_task_exe_path in
> the helpers function to get.
> 
> The code currently only submits the implementation of the function and
> how is this patch merge possible if I then add the relevant places。
> 
> thanks
> mangosteen728
> kernel/bpf/helpers.c | 37 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index 225806a..797f 850 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -257,6 +257,43 @@
> .arg2_type = ARG_CONST_SIZE,
> };
> 
> +BPF_CALL_3(bpf_get_task_exe_path, struct task_struct *, task, char *,
> buf, u32, sz)
> +{
> + struct file *exe_file = NULL;
> + char *p = NULL;
> + long len = 0;
> +
> + if (!sz)
> + return 0;
> + exe_file = get_task_exe_file(tsk);
> + if (IS_ERR_OR_NULL(exe_file))
> + return 0;
> + p = d_path(&exe_file->f_path, buf, sz);
> + if (IS_ERR_OR_NULL(path)) {
> + len = PTR_ERR(p);
> + } else {
> + len = buf + sz - p;
> + memmove(buf, p, len);
> + }
> + fput(exe_file);
> + return len;
> +}
> +
> +static const struct bpf_func_proto bpf_get_task_exe_path_proto = {
> + .func       = bpf_get_task_exe_path,
> + .gpl_only   = false,
> + .ret_type   = RET_INTEGER,
> + .arg1_type  = ARG_PTR_TO_BTF_ID,
> + .arg2_type  = ARG_PTR_TO_MEM,
> + .arg3_type  = ARG_CONST_SIZE_OR_ZERO,
> +};
> +

Something went really wrong with your patch :(

But the larger issue is, there is no such thing as a "absolute path to a
file" within the kernel, sorry.  This just is not going to work, and it
has come up again and again and again with regards to other kernel
subsystems many times.

Step back and answer "why" you think you need a path to an executable?
What needs this that you can not do it in userspace?  What are you going
to do with this supposed information if you get it?

And then think about filesystem namespaces...

sorry, this isn't going to work.

greg k-h