wg: add a test for the home jail socket feature

[kevans]

Summary

This adds a test for a semantic that we added to mirror a feature of
the Linux implementation w/ netns: if a wg interface is moved into a
jail, we still create the socket in the context of the home vnet. With
this added, one can actually create vnet jails that only have a wg
tunnel to the outside world providing network connectivity without any
epairs in the setup.

While we're here, PR 254212 was resolved to avoid issues with not having
IPv6 addresses present in the jail, so let's just drop that workaround.

[zlei]

if a wg interface is moved into a
jail, we still create the socket in the context of the home vnet.

I think that is technically possible.
The idea is somewhat similar with SIOC[SG]TUNFIB vs SIOC[SG]IFFIB , it is TUN VNET vs IF VNET.

With this added, one can actually create vnet jails that only have a wg
tunnel to the outside world providing network connectivity without any
epairs in the setup

Then processes in child vnet shall not operate (get or set) the tunnel part of ifnet, unless explicitly permitted.
And it will also be complicated to operate the tunnel part of ifnet in home vnet.

[kevans]

In D37755#858722, @zlei wrote:

if a wg interface is moved into a
jail, we still create the socket in the context of the home vnet.

I think that is technically possible.
The idea is somewhat similar with SIOC[SG]TUNFIB vs SIOC[SG]IFFIB , it is TUN VNET vs IF VNET.

With this added, one can actually create vnet jails that only have a wg
tunnel to the outside world providing network connectivity without any
epairs in the setup

Then processes in child vnet shall not operate (get or set) the tunnel part of ifnet, unless explicitly permitted.
And it will also be complicated to operate the tunnel part of ifnet in home vnet.

This is a feature already implemented- when the interface is created, we hold a reference to the current thread's ucred and use that in socket creation instead of the context at the time of creation. We just didn't have any test coverage for it, yet.

We don't allow the flexibility of changing which vnet the socket is created in on the fly, though... imo if you wanted a tunnel in the current vnet you could have just created it yourself, or your parent could have created the tunnel in your vnet to begin with. We don't want the child to be able to selectively push a socket into the parent's context that the parent didn't bless, so I think we can get away without any added complexity here.

[zlei]

In D37755#858824, @kevans wrote:

In D37755#858722, @zlei wrote:

if a wg interface is moved into a
jail, we still create the socket in the context of the home vnet.

I think that is technically possible.
The idea is somewhat similar with SIOC[SG]TUNFIB vs SIOC[SG]IFFIB , it is TUN VNET vs IF VNET.

With this added, one can actually create vnet jails that only have a wg
tunnel to the outside world providing network connectivity without any
epairs in the setup

Then processes in child vnet shall not operate (get or set) the tunnel part of ifnet, unless explicitly permitted.
And it will also be complicated to operate the tunnel part of ifnet in home vnet.

This is a feature already implemented- when the interface is created, we hold a reference to the current thread's ucred and use that in socket creation instead of the context at the time of creation. We just didn't have any test coverage for it, yet.

Sorry I have not full looked through the if_wg code and did not know the feature is already implemented .

We don't allow the flexibility of changing which vnet the socket is created in on the fly, though... imo if you wanted a tunnel in the current vnet you could have just created it yourself, or your parent could have created the tunnel in your vnet to begin with. We don't want the child to be able to selectively push a socket into the parent's context that the parent didn't bless, so I think we can get away without any added complexity here.

Looks reasonable!

[markj]

tests/sys/net/if_wg.sh

192

243

I'd maybe go a bit further and try to check that the ICMP packets really are being handled by the jail vnets. Something like checking the netstat -s -p icmp counters in both jails. Just a suggestion, I don't think it's required for the test to be useful.

248

Does this handle destroying the wg interfaces? I thought they would just get rehomed to the jail host.

[jhb]

tests/sys/net/if_wg.sh

62

I would maybe split this out as a separate commit?

248

Hmm, if not we need to fix the other tests. I feel like I don't see leaked wg interfaces from the other tests when I've run them though.

[markj]

tests/sys/net/if_wg.sh

248

The other tests create the interfaces inside the vnets rather than moving them in. I'm not certain at all, but I believe they'll get destroyed together with their vnets. Here we're creating the interfaces on the host and attaching them to vnets.

[kevans]

tests/sys/net/if_wg.sh

248

Yup- vnet_mkjail records the vnet.interface it sets, vnet_cleanup destroys all of those interfaces in the first branch:

if [ -f created_jails.lst ]; then                                       
        while read jailname ifnames; do                                 
                for ifname in ${ifnames}; do                            
                        jexec ${jailname} ifconfig ${ifname} destroy    
                done                                                    
                jail -r ${jailname}                                     
        done < created_jails.lst                                        
        rm created_jails.lst                                            
fi