Restricting network access using Linux Network Namespaces | Hacker News Reader

Restricting network access using Linux Network Namespaces

blog.sigma-star.at

100 pointsDeeg9rie9usi25 comments

This part is so cool:

>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].

[0]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

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.

Wait for ppl come and start claiming you are against UNIX philosophy and systemd fanboy :))

Socket activated services first appeared in inetd(8) somewhere in the eighties and is as UNIX as it gets :)

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.

See this comment: https://news.ycombinator.com/item?id=35862698

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.

Is there any way to do that for systems without systemd, like Devuan?

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.

https://skarnet.org/software/s6/s6-fdholderd.html

https://wiki.gentoo.org/wiki/S6/File_descriptor_holder

http://www.skarnet.org/software/s6/socket-activation.html

Thanks!

> almost all my services run in VMs/on dedicated hardware

Sounds like you could benefit from Qubes OS.

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.

Just share an open FD to a socks proxy with the isolated service.

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.

As another commenter says, you can use socat. Specifically, you can run it in double client mode (see http://www.dest-unreach.org/socat/doc/socat-gender.txt) to connect the UNIX socket to the service.

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.

https://sandstorm.io/

OP's comments are all about Sandstorm FYI

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.

Here is an example I linked in another comment: http://www.dest-unreach.org/socat/doc/socat-gender.txt

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.

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.

Use socket activation and run your service with PrivateNetwork=yes

This blog post could really use a more specific (basic) example how to set up a virtual container network.

Search the internet for combinations of "ip link", "netns", "tunnel", "veth". Eg:

- https://adil.medium.com/container-networking-under-the-hood-...

- https://www.redhat.com/sysadmin/net-namespaces

Reply on news.ycombinator.com