Setting the transit namespace at runtime

Jason A. Donenfeld Jason at
Mon Sep 10 00:27:43 CEST 2018

Hi Julian,

On Fri, Sep 7, 2018 at 1:06 PM Julian Orth <ju.orth at> wrote:
> > I'd thought of this early on, but failed to come up with what seemed
> > like an actually realistic use case for it.
> How about creating Wireguard devices as a user that has no
> privileges/capabilites in the init namespace?
> $ unshare -r -U -m
> $ mount --bind /proc/self/ns/net init-ns
> $ unshare -n
> $ ./
> $ wg set wg0 transit-net init-ns

That looks to me like a security vulnerability. User namespace sets
listen-port to < 1024, and then moves it into the target namespace,
and bam, controls subverted.

It might be wise, then, to include with this a capability check
relative to the destination socket namespace, but that needs a check
on both ends -- when you change the socket namespace and when you
change the listen port, to make sure they correspond. However, if
you're restricting setting the namespace and the listen port to
cap_net_admin, then the above is no longer a good reason for this
patchset, thereby begging my initial question.

I saw you posted patches to the mailing list. I'll review these soon
on my way back home on the flight tomorrow. In the mean time, if you
send me your SSH public key (perhaps privately), we can add you to the
WireGuard git repository, so that you can push to branches that begin
with "jo/".


More information about the WireGuard mailing list