netdev - Re: VRF Issue Since kernel 5

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]

Message-ID: <d81f97fe-be4b-041d-1233-7e69758d96ef@vyatta.att-mail.com>
Date:   Wed, 8 Apr 2020 11:07:31 +0100
From:   Mike Manning <mmanning@...tta.att-mail.com>
To:     Maximilian Bosch <maximilian@...sch.me>, netdev@...r.kernel.org
Cc:     David Ahern <dsahern@...il.com>
Subject: Re: VRF Issue Since kernel 5

Hi Maximilian,
Can you please clarify what the issue is with using 'ip vrf exec <vrf>
ssh' for running the ssh client in the vrf? This is the recommended
method for running an application in a VRF. As part of our VRF
development on this a couple of years ago, we provided a changeset for
openssh so that the vrf could be specified as an option, cf
https://bugzilla.mindrot.org/show_bug.cgi?id=2784. That was not applied
due to the ease of using 'ip vrf exec'.

Alternatively, to run the ssh client in the default VRF, you can bind it
to an address on an interface (or specify the interface) in the default
VRF using ssh -b (or -B) option, or similarly add an entry in
/etc/ssh/ssh_config for BindAddress (or BindInterface).

Then for egress, leak a route in the default table to get to the gateway
via the VRF (as you must already be doing), and for ingress, leak a
route in the VRF's table for the return path to the ssh client. For
this, get the table id for the vrf from 'ip vrf', add the route for the
client prefix with the additional 'table <tbl-id>' option, and confirm
the route with 'ip route show vrf <vrf-name>'.

I have started looking at the issue you have reported, but as you may
appreciate, it is not trivial. This client-side use-case is not typical,
as VRF config is generally applied to routers or switches, not hosts.

Thanks
Mike

On 05/04/2020 17:52, David Ahern wrote:
> On 4/2/20 5:02 PM, Maximilian Bosch wrote:
>> Hi!
>>
>>> I do not see how this worked on 4.19. My comment above is a fundamental
>>> property of VRF and has been needed since day 1. That's why 'ip vrf
>>> exec' exists.
>> I'm afraid I have to disagree here: first of all, I created a
>> regression-test in NixOS for this purpose a while ago[1]. The third test-case
>> (lines 197-208) does basically what I demonstrated in my previous emails
>> (opening SSH connetions through a local VRF). This worked fine until we
>> bumped our default kernel to 5.4.x which is the reason why this testcase
>> is temporarily commented out.
> I do not have access to a NixOS install, nor the time to create one.
> Please provide a set of ip commands to re-create the test that work with
> Ubuntu, debian or fedora.
>
>
>> After skimming through the VRF-related changes in 4.20 and 5.0 (which
>> might've had some relevant changes as you suggested previously), I
>> rebuilt the kernels 5.4.29 and 5.5.13 with
>> 3c82a21f4320c8d54cf6456b27c8d49e5ffb722e[2] reverted on top and the
>> commented-out testcase works fine again. In other words, my usecase
>> seems to have worked before and the mentioned commit appears to cause
>> the "regression".
> The vyatta folks who made the changes will take a look.