[Feature suggestion] xsocket protocol support (dealing with network namespaces, fwmarks and VRFs without elevated privileges).

[przemyslaw0]

Remember, it's just a suggestion.

@folbricht

Dealing with network namespaces using setns() requires CAP_SYS_ADMIN, it could be dangerous if the program has unknown bugs and vulnerabilities, that's why an alternative approach is needed.

There is a socket library called xsocket, it is a socket library that can use a cross-netns fashion to avoid requiring elevated privileges such as CAP_SYS_ADMIN, the only need of a root access is running the library server itself, which is by far more secure and trusty as it a very small program and have a minimal attack surface area:

ip netns exec foo sudo -u bar -- xsocket-server /tmp/xs-socket

nsenter -t 1234 -n -- sudo -u bar -- xsocket-server /tmp/xs-socket

I know that is a little known project, but it's promising. The only security notes on using this protocol is adjusting the user/group/chmod permissions and ACLs on the xsocket-server Unix sockets.

I'm sending an attachment that contains two reference implementations of how to implement xsocket protocol in Go (don't laugh, it's AI):

xsocket_pf.zip

[folbricht]

It doesn't integrate too well and it's still somewhat niche.

If all you want to achieve is not need CAP_SYS_ADMIN, you should be able to use it anyway though, without code changes. xsocket ships an LD_PRELOAD shim (libxbind.so) that transparently intercepts bind() and routes the listening socket into the target namespace. You should be able to run the existing RouteDNS binary under it without any changes on our side.

Something like

LD_PRELOAD=libxbind.so XBIND=53 XSOCKET=/run/xsocket/foo.sock routedns config.toml

See https://github.com/koro666/xsocket#injection

[przemyslaw0]

@folbricht

libxbind.so doesn't work with Go binaries as syscalls socket()/bind() are not exposed as you can see if you run RouteDNS with strace. There is another client for xsocket: https://github.com/schropkev/lysekrone

A possible usage would be:

[resolvers.res]
address = "9.9.9.9:53"
protocol = "udp"
query-timeout = 10
xsocket = /var/tmp/xsocket/ns1

[listeners.local-udp-ipv4]
address = "[::]:1053"
protocol = "udp"
resolver = "res"

[listeners.local-tcp-ipv4]
address = "[::]:1053"
protocol = "tcp"
resolver = "res"
xsocket = /var/tmp/xsocket/ns2

But it's ok, if you want you can close this topic.

[folbricht]

Whipped something up with Claude but it's quite a large and intrusive change. And it's likely going to conflict with #522 too.

Not sure it's worth the complexity tbh

[przemyslaw0]

@folbricht

It's just picking up the socket parameters, and send over the xsocket-server Unix socket together with XS_PROTOCOL_REQUEST at the top of message and receiving XS_PROTOCOL_RESPONSE + error message (0 or 1) back: https://github.com/koro666/xsocket/blob/master/protocol.h - The xsocket-server Unix socket is of type SOCK_SEQPACKET.

If it was possible to implement SO_MARK and SO_BINDTODEVICE at socket level with RouteDNS, maybe it should be possible to implement xsocket support at socket level too, but not by making a large and intrusive change. Can the already implemented SO_MARK and SO_BINDTODEVICE serve as a basis? Another question would be if it's worth the risk of running a program with CAP_SYS_ADMIN just for a feature, the only capability a DNS program should have it's CAP_NET_BIND_SERVICE.

But it's ok, if you find it doesn't worth the effort, close this topic.

Thanks.

[folbricht]

Let's iterate on this a bit more. The goal is the cleanest overall design rather than maximizing the xsocket PR. Here are some thoughts:

• Add socket-activation support for listeners (LISTEN_FDS). Standard, dependency-free, also fixes privileged ports. Arguably belongs in RouteDNS regardless of this issue.
• I could add a sub-command to RouteDNS itself to run an fd-server only for resolvers, where it's unavoidable and prefer a first-party helper over depending on the external xsocket-server protocol. routedns netns-helper ... would run privileged and the main process could use it.
• Document VRF/fwmark as a non-namespace path using the existing bind-if.

Thoughts?

In the meantime, I rebased the xsocket PR on master so all the recent changes are in it now.

[przemyslaw0]

@folbricht

I could add a sub-command to RouteDNS itself to run an fd-server only for resolvers, where it's unavoidable and prefer a first-party helper over depending on the external xsocket-server protocol. routedns netns-helper ... would run privileged and the main process could use it.

Why not use a proper executable for fd-server instead of adding as a sub-command in RouteDNS? If I need to run 50 RouteDNS's I would need to run another 50 ones for fd-processing. The server would be very small, easy to implement.

fd-server only for resolvers

Only for resolvers? Add for listeners too, so I can run the fd-server in LXC with a bind mount and make RouteDNS listen inside the container, of course, setting users/groups/chmods/ACLs too.