yggdrasil-go
yggdrasil-go copied to clipboard
Add support for using a pre-existing pre-configured `tun` interface (in order to support root-less execution)
At the moment yggdrasil
requires administrative permissions (usually root
via sudo
) in order to create and initialize the tun
device.
However, one could create the tun
interface manually as for example with:
ip tuntap add \
dev ygg0 \
mode tun \
user "${UID}" \
group "${UID}" \
#
ip link set dev ygg0 mtu 65535
Then just use ygg0
in the configuration file.
At the moment this runs up to the point where yggdrasil
tries to configure the MTU for the intreface. I assume what remains to be configured is the IP from 200:
and 300:
range; however those are deterministic, thus could be initialized as above.
What I'm asking is a configuration item (or even command line flag), that would just use the existing tun
interface (as denoted by the IfName
configuration), and just don't try to configure it, but use it as is.
This would allow one to run yggdrasil
without any priviledges, perhaps in a more strict "sandbox", and thus making sure it only handles the network and not touching the rest of the system.
(BTW, a similar setup is already possible with Wireguard as implemented in Go.)
This would neatly solve the "yggdrasil in containers" conundrum!
This would neatly solve the "yggdrasil in containers" conundrum!
@jgoerzen Indeed it would also solve the containers deployment, but also other non-standard deployments; for example I wonder if one couldn't point yggdrasil
to an existing tun
interface that is passed to a Qemu (or similar) VM? (Thus that VM would always exit through the yggdrasil
network.)
BTW, I am open for testing such a patch. (I can build it on Linux.)
Isn't CAP_NET_ADMIN capability enough to run from an unprivileged user?
It may be, though the example systemd files also give CAP_NET_RAW and CAP_NET_BIND_SERVICE.
Still, CAP_NET_ADMIN is quite extensive and represents more privilege than I would want to give a container.