netdev - Re: [bpf-next PATCH 2/3] bpf: sk_msg helpers for probe_* and *current

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: <5ebd480fa503a_7f582b1a484825b47a@john-XPS-13-9370.notmuch>
Date:   Thu, 14 May 2020 06:30:55 -0700
From:   John Fastabend <john.fastabend@...il.com>
To:     Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>, ast@...nel.org,
        daniel@...earbox.net
Cc:     lmb@...udflare.com, bpf@...r.kernel.org, jakub@...udflare.com,
        netdev@...r.kernel.org
Subject: Re: [bpf-next PATCH 2/3] bpf: sk_msg helpers for probe_* and
 *current_task*

Yonghong Song wrote:
> 
> 
> On 5/13/20 12:24 PM, John Fastabend wrote:
> > Often it is useful when applying policy to know something about the
> > task. If the administrator has CAP_SYS_ADMIN rights then they can
> > use kprobe + sk_msg and link the two programs together to accomplish
> > this. However, this is a bit clunky and also means we have to call
> > sk_msg program and kprobe program when we could just use a single
> > program and avoid passing metadata through sk_msg/skb, socket, etc.
> > 
> > To accomplish this add probe_* helpers to sk_msg programs guarded
> > by a CAP_SYS_ADMIN check. New supported helpers are the following,
> > 
> >   BPF_FUNC_get_current_task
> >   BPF_FUNC_current_task_under_cgroup
> >   BPF_FUNC_probe_read_user
> >   BPF_FUNC_probe_read_kernel
> >   BPF_FUNC_probe_read
> >   BPF_FUNC_probe_read_user_str
> >   BPF_FUNC_probe_read_kernel_str
> >   BPF_FUNC_probe_read_str
> 
> I think this is a good idea. But this will require bpf program
> to be GPLed, probably it will be okay. Currently, for capabilities,
> it is CAP_SYS_ADMIN now, in the future, it may be CAP_PERFMON.

Right.

> 
> Also, do we want to remove BPF_FUNC_probe_read and
> BPF_FUNC_probe_read_str from the list? Since we
> introduce helpers to new program types, we can deprecate
> these two helpers right away.

Removed, Daniel had the same comment.

> 
> The new helpers will be subject to new security lockdown
> rules which may have impact on networking bpf programs
> on particular setup.

But only if these helpers are used. If not everything should
be the same I think.

> 
> > 
> > Signed-off-by: John Fastabend <john.fastabend@...il.com>
> > ---

[...]

> > @@ -6397,6 +6406,31 @@ sk_msg_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> >   		return &bpf_get_cgroup_classid_curr_proto;
> >   #endif
> >   	default:
> > +		break;
> > +	}
> > +
> > +	if (!capable(CAP_SYS_ADMIN))
> > +		return bpf_base_func_proto(func_id);
> > +
> > +	/* All helpers below are for CAP_SYS_ADMIN only */
> > +	switch (func_id) {
> > +	case BPF_FUNC_get_current_task:
> > +		return &bpf_get_current_task_proto;
> > +	case BPF_FUNC_current_task_under_cgroup:
> > +		return &bpf_current_task_under_cgroup_proto;
> > +	case BPF_FUNC_probe_read_user:
> > +		return &bpf_probe_read_user_proto;
> > +	case BPF_FUNC_probe_read_kernel:
> > +		return &bpf_probe_read_kernel_proto;
> > +	case BPF_FUNC_probe_read:
> > +		return &bpf_probe_read_compat_proto;
> > +	case BPF_FUNC_probe_read_user_str:
> > +		return &bpf_probe_read_user_str_proto;
> > +	case BPF_FUNC_probe_read_kernel_str:
> > +		return &bpf_probe_read_kernel_str_proto;
> > +	case BPF_FUNC_probe_read_str:
> > +		return &bpf_probe_read_compat_str_proto;
> > +	default:
> >   		return bpf_base_func_proto(func_id);
> 
> If we can get a consensus here, I think we can even folding all
> these bpf helpers (get_current_task, ..., probe_read_kernel_str)
> to bpf_base_func_proto, so any bpf program types including
> other networking types can use them.
> Any concerns?
> 

Nothing comes to mind. I'm OK to move them into base if folks
agree its useful there. I was putting them where I have a known
use case at the moment but doesn't bother me to make them more
widely available.