netdev - Re: Matching unbound sockets for VRF

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:   Mon, 4 Apr 2022 08:41:04 -0400
From:   Stephen Suryaputra <ssuryaextr@...il.com>
To:     David Ahern <dsahern@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: Matching unbound sockets for VRF

On Sun, Apr 03, 2022 at 10:24:36AM -0600, David Ahern wrote:
> On 3/27/22 6:57 AM, Stephen Suryaputra wrote:
> > 
> > The reproducer script is attached.
> > 
> 
> h0 has the mgmt vrf, the l3mdev settings yet is running the client in
> *default* vrf. Add 'ip vrf exec mgmt' before the 'nc' and it works.

Yes. With "ip vrf exec mgmt" nc would work. We know that. See more
below.

> Are you saying that before Mike and Robert's changes you could get a
> client to run in default VRF and work over mgmt VRF? If so it required
> some ugly routing tricks (the last fib rule you installed) and is a bug
> relative to the VRF design.

Yes, before Mike and Robert's changes the client ran fine because of the
last fib rule. We did that because some of our applications are:
1) Pre-dates "ip vrf exec"
2) LD_PRELOAD trick from the early days doesn't work

On the case (2) above, one concrete example is NFS mounting our images:
applications and kernel modules. We had to run less than full-blown
utilities and also the mount command uses glibc RPC functions
(pmap_getmaps(), clntudp_create(), clnt_call(), etc, etc.). We analyzed
it back then that because these functions are in glibc and call socket()
from within glibc, the LD_PRELOAD doesn't work.

>From the thread of Mike and Robert's changes, the conclusion is that the
previous behavior is a bug but we have been relying on it for a while,
since the early days of VRFs, and an upgrade that includes the changes
caused some applications to not work anymore.

I'm asking if Mike and Robert's changes should be controlled by an
option, e.g. sysctl, and be the default. But can be reverted back to the
previous behavior.

Thanks,
Stephen.