>Please note that network namespaces, actually Linux namespaces in general, have no influence on existing file handles. Therefore, if your application possesses a file handle to a socket from another network namespace, it can use it in the new network namespace smoothly.
>This is a useful feature as it allows creating network servers that can serve a listening socket but are disconnected from the outside world. If an attacker manages to overtake the application, they are unable to create a new socket. Here you can find a sample application that outlines the idea.
I always find stuff like this cool. Being able to still use the resources you acquired before you dropped privileges. Some related concepts I also love are capabilities and CHERI[0].
As the section at the end says, socket fds work even if the process doesn't have access to the underlying network interface that they were bound from. A good use of this fact is that it's okay to set `PrivateNetwork=yes` for socket-activated systemd services.
I'd hardly call it services, in terms of what inetd could do to keep the _service_, more like wrappers, but yeah. Systemd made it better - I run both xinetd based bash scripts for sorta network-accessible healthchecks used by haproxy later and 8000+ systemd's socket activated services, can compare apples to apples.
I see so much discussion of preventing _local_ escalation, but at this point almost all my services run in VMs/on dedicated hardware. Superuser powers don't buy you anything extra there.
What I really would like more discussed is _network_ isolation. You don't need root to exfiltrate tons of data.
If you implement socket activation and use an empty network namespace your service can be totally disconnected from any network and still handle requests (because the socket FD it listens on was inherited from systemd). This makes exfiltration much more difficult.
Sure, s6 has the same feature. Systemd just made up a fancy name ("socket activation") for it which is why people mistakenly assume you need systemd for it.
Something I've wanted to do is run less trusted services on a private network but still have the reverse proxy connect to them. This way I can be sure that they only way to get to them from the outside is via the reverse proxy (which adds authentication). However I haven't found a decent way to manage that no network access paired with a loopback or similar that can be accessed by the reverse proxy.
Can run it in a isolated namespace and communicate with unix sockets. If the service does not support listening on sockets you can use socat within the namespace to forward from the unix socket to a port on lo in the namespace. Most reverse proxies can forward to a unix socket.
I've done similar things (and sometimes with a wireguard tunnel out to internet) for privacy reasons.
Create a veth pair. Move one end of the pair into a network namespace. Bind the untrusted service on that end. Have your proxy service connect to the other end.
You've just described Sandstorm. Sandstorm runs instances (called grains) of applications in a sandbox. The application gets a limited file system and a Cap'n Proto RPC connection to the outside world over a unix socket. Sandstorm runs the HTTPS server, which turns requests into RPC calls. Sandstorm authenticates the users and provides temporary subdomains and frames to sandbox the HTML side of it.
I have less trusted services all listening on my Tailscale network. Network ACLs can then ensure they can't talk to each other and the only thing that can talk to them is the reverse proxy.
This depends on the service itself supporting inheriting sockets for proxies. Is this a common feature? Some services do support listening socket passing which does solve my problem as I can make it listen on a UNIX socket mounted on the host and accessible to the reverse proxy but many of the lower quality services that I want to give this treatment to don't support that either.
>Please note that network namespaces, actually Linux namespaces in general, have no influence on existing file handles. Therefore, if your application possesses a file handle to a socket from another network namespace, it can use it in the new network namespace smoothly.
>This is a useful feature as it allows creating network servers that can serve a listening socket but are disconnected from the outside world. If an attacker manages to overtake the application, they are unable to create a new socket. Here you can find a sample application that outlines the idea.