From: Stanislav Fomichev <sdf@google.com>
To: Andrey Ignatov <rdna@fb.com>
Cc: Martin KaFai Lau <kafai@fb.com>, Netdev <netdev@vger.kernel.org>,
bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>
Subject: Re: [PATCH bpf-next 1/2] bpf: allow rewriting to ports under ip_unprivileged_port_start
Date: Fri, 22 Jan 2021 11:53:51 -0800 [thread overview]
Message-ID: <CAKH8qBumq7cHDeCpvA1T_rJyvY8+9uCUyb--YAhvcAx3p58faw@mail.gmail.com> (raw)
In-Reply-To: <YAspc5rk2sNWojDQ@rdna-mbp.dhcp.thefacebook.com>
On Fri, Jan 22, 2021 at 11:37 AM Andrey Ignatov <rdna@fb.com> wrote:
>
> Stanislav Fomichev <sdf@google.com> [Wed, 2021-01-20 18:09 -0800]:
> > At the moment, BPF_CGROUP_INET{4,6}_BIND hooks can rewrite user_port
> > to the privileged ones (< ip_unprivileged_port_start), but it will
> > be rejected later on in the __inet_bind or __inet6_bind.
> >
> > Let's export 'port_changed' event from the BPF program and bypass
> > ip_unprivileged_port_start range check when we've seen that
> > the program explicitly overrode the port. This is accomplished
> > by generating instructions to set ctx->port_changed along with
> > updating ctx->user_port.
> >
> > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > ---
> ...
> > @@ -244,17 +245,27 @@ int bpf_percpu_cgroup_storage_update(struct bpf_map *map, void *key,
> > if (cgroup_bpf_enabled(type)) { \
> > lock_sock(sk); \
> > __ret = __cgroup_bpf_run_filter_sock_addr(sk, uaddr, type, \
> > - t_ctx); \
> > + t_ctx, NULL); \
> > release_sock(sk); \
> > } \
> > __ret; \
> > })
> >
> > -#define BPF_CGROUP_RUN_PROG_INET4_BIND_LOCK(sk, uaddr) \
> > - BPF_CGROUP_RUN_SA_PROG_LOCK(sk, uaddr, BPF_CGROUP_INET4_BIND, NULL)
> > -
> > -#define BPF_CGROUP_RUN_PROG_INET6_BIND_LOCK(sk, uaddr) \
> > - BPF_CGROUP_RUN_SA_PROG_LOCK(sk, uaddr, BPF_CGROUP_INET6_BIND, NULL)
> > +#define BPF_CGROUP_RUN_PROG_INET_BIND_LOCK(sk, uaddr, type, flags) \
> > +({ \
> > + bool port_changed = false; \
>
> I see the discussion with Martin in [0] on the program overriding the
> port but setting exactly same value as it already contains. Commenting
> on this patch since the code is here.
>
> From what I understand there is no use-case to support overriding the
> port w/o changing the value to just bypass the capability. In this case
> the code can be simplified.
>
> Here instead of introducing port_changed you can just remember the
> original ((struct sockaddr_in *)uaddr)->sin_port or
> ((struct sockaddr_in6 *)uaddr)->sin6_port (they have same offset/size so
> it can be simplified same way as in sock_addr_convert_ctx_access() for
> user_port) ...
>
> > + int __ret = 0; \
> > + if (cgroup_bpf_enabled(type)) { \
> > + lock_sock(sk); \
> > + __ret = __cgroup_bpf_run_filter_sock_addr(sk, uaddr, type, \
> > + NULL, \
> > + &port_changed); \
> > + release_sock(sk); \
> > + if (port_changed) \
>
> ... and then just compare the original and the new ports here.
>
> The benefits will be:
> * no need to introduce port_changed field in struct bpf_sock_addr_kern;
> * no need to do change program instructions;
> * no need to think about compiler optimizing out those instructions;
> * no need to think about multiple programs coordination, the flag will
> be set only if port has actually changed what is easy to reason about
> from user perspective.
>
> wdyt?
Martin mentioned in another email that we might want to do that when
we rewrite only the address portion of it.
I think it makes sense. Imagine doing 1.1.1.1:50 -> 2.2.2.2:50 it
seems like it should also work, right?
And in this case, we need to store and compare addresses as well and
it becomes messy :-/
It also seems like it would be nice to have this 'bypass
cap_net_bind_service" without changing the address while we are at it.
next prev parent reply other threads:[~2021-01-22 22:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-21 1:22 [PATCH bpf-next 1/2] bpf: allow rewriting to ports under ip_unprivileged_port_start Stanislav Fomichev
2021-01-21 1:22 ` [PATCH bpf-next 2/2] selftests/bpf: verify that rebinding to port < 1024 from BPF works Stanislav Fomichev
2021-01-21 22:33 ` Martin KaFai Lau
2021-01-21 22:57 ` sdf
2021-01-21 23:50 ` Martin KaFai Lau
2021-01-22 0:30 ` sdf
2021-01-22 1:27 ` Martin KaFai Lau
2021-01-22 16:16 ` sdf
2021-01-22 19:38 ` Martin KaFai Lau
2021-01-22 19:56 ` Stanislav Fomichev
2021-01-21 23:53 ` Andrii Nakryiko
2021-01-22 0:09 ` sdf
2021-01-22 0:24 ` Andrii Nakryiko
2021-01-22 19:37 ` [PATCH bpf-next 1/2] bpf: allow rewriting to ports under ip_unprivileged_port_start Andrey Ignatov
2021-01-22 19:53 ` Stanislav Fomichev [this message]
2021-01-22 20:08 ` Andrey Ignatov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKH8qBumq7cHDeCpvA1T_rJyvY8+9uCUyb--YAhvcAx3p58faw@mail.gmail.com \
--to=sdf@google.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kafai@fb.com \
--cc=netdev@vger.kernel.org \
--cc=rdna@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).