openssh unix dev - Jul 2021 - Implementing IP_FREEBIND in OpenSSH

Dear Damien,

On Tue, Jul 27, 2021 at 2:55 AM Damien Miller <djm at mindrot.org> wrote:
> On Mon, 26 Jul 2021, Dmitry Belyavskiy wrote:
>
> > The solution can be made more or less portable: BSD systems support
> similar
> > functionality SO_BINDANY, which can make it more acceptable upstream.
> > FreeBSD support different flag names with the same semantics in
different
> > versions: IP_FREEBIND, IP_NONLOCALOK for older versions,
> > IP_BINDANY/IPV6_BINDANY. Using such options in FreeBSD and other BSD
> > systems may require extra privileges.
>
> I don't know whether IP_FREEBIND is exactly equivalent to SO_BINDANY.
>
> The getsockopt(2) manual page on OpenBSD talks discusses SO_BINDANY
> primarily in the context of transparent proxying and mentions that
> packet filter rules need to be configured to actually use it. It
> isn't clear whether it offers the same "prospective use" as
what you
> want from IP_FREEBIND.
>
Quoting https://man.openbsd.org/getsockopt.2

SO_BINDANY allows the socket to be bound to addresses which are not local
to the machine, so it can be used to make a transparent proxy. Note that
this option is limited to the superuser.

It looks like that it solves the problem under discussion, but has its
downsides.

>
> Couldn't you achieve the same result without modification to sshd
> by using the ip_nonlocal_bind flag in the Linux kernel?
>
Yes, it is a possible workaround, but this flag is system-level one, so it
doesn't provide any granularity.


-- 
Dmitry Belyavskiy

On Tue, 27 Jul 2021, Dmitry Belyavskiy wrote:
> >
> > Couldn't you achieve the same result without modification to sshd
> > by using the ip_nonlocal_bind flag in the Linux kernel?
> >
> 
> Yes, it is a possible workaround, but this flag is system-level one, so it
> doesn't provide any granularity.
Perhaps make ip_nonlocal_bind=2 allow root to bind non-locally without
restriction. That might solve the problem for sshd and all other network
daemons?

Otherwise, I don't want to add another configuration directive for a
niche, platform-specific feature when the same effect could be achieved
though existing configuration (systemd dependencies, socket activation,
wildcard bind plus packet filtering, etc). 

If SO_BINDANY does turn out to be cross platform without heavy caveats,
then perhaps a flag on this existing Listen directive would be more
acceptable, e.g. "Listen 111.222.33.44 bindany" - there is prior art
for such flags in the existing "rdomain" one.

-d