IP2Unix - Turn IP sockets into Unix domain sockets

Executes a program and converts IP to Unix domain sockets at runtime via LD_PRELOAD (ld.so(8)) based on a list of rules, either given via short command line options (see Rule specification) or via a file containing a list of rules separated via newline. The first matching rule causes ip2unix to replace the current IP socket with a Unix domain socket based on the options given. For example if a path is specified, the Unix domain socket will bind or listen to the file given.

Problem statement

A lot of programs are designed to only work with IP sockets, however very few of them allow to communicate via Unix domain sockets. Unix domain sockets usually are just files, so standard Unix file permissions apply to them.

IP sockets also have the disadvantage that other programs on the same host are able to connect to them, unless you use complicated netfilter rules or network namespaces.

So if you either have a multi-user system or just want to separate privileges, Unix domain sockets are a good way to achieve that.

Another very common use case in nowadays systems is when you’re using systemd and want to use socket units for services that don’t support socket activation. Apart from getting rid of the necessity to specify explicit dependencies, this is also very useful for privilege separation, since a lot of services can be run in a separate network namespace.

The systemd use case is also useful even when not using Unix domain sockets in socket units, since it allows to add IP-based socket activation to services that don’t support it.

Short example

Let’s say you have a small HTTP server you want to make available behind a HTTP reverse proxy.

$ ip2unix -r path=/run/my-http-server.socket my-http-server

This will simply convert all IP sockets to the Unix domain socket available at /run/my-http-server.socket. If you use a web server like nginx, you can use the following directive to connect to that socket:

proxy_pass http://unix:/run/my-http-server.socket;

More examples can be found further below in section Examples.

A short summary of all the options is available via ip2unix --help or man ip2unix if you want to see all the details and options available.

1. Build from source
2. Rule specification
3. Rule matching behaviour
4. Examples
- 4.1. Simple HTTP client/server
- 4.2. More complicated example
5. Limitations
6. Frequently Asked Questions
- 6.1. Isn’t this functionality already covered by socat?
- 6.2. Yes, but can’t this still be done via socat and the iptables owner module?
7. Similar projects
8. Thanks
9. Copyright

1. Build from source

See INSTALL.adoc for information on how to build and/or install ip2unix on your system.

2. Rule specification

Arguments specified via -r contain a comma-separated list of either flags or options. If a value contains a comma (,), it has to be escaped using a backslash (\) character. If you want to have a verbatim backslash character just use two consecutive backslashes instead.

The following flags are available:

in | out: Whether this rule applies to a server-side socket (in), a client-side socket (out) or both if neither in nor out is specified.
tcp | udp: Specifies the IP type, which currently is either tcp for TCP sockets, udp for UDP sockets or if it is not defined it matches both UDP and TCP sockets.
systemd[=FD_NAME]: Use the socket passed along via file descriptor by systemd instead of creating one.

An optional file descriptor name (FD_NAME) can be specified to distinguish between several socket units. This corresponds to the FileDescriptorName systemd socket option.
reject[=ERRNO]: Reject calls to connect and bind with EACCES by default or the ERRNO specified either via name or as an integer.
blackhole: Turn the socket into a Unix domain socket but do not make it available for clients to connect. This is useful to deactive certain sockets without causing errors in the application (unlike reject).

Technically, this means that we bind to a Unix socket using a temporary file system path and unlink it shortly thereafter.
ignore: Prevents a socket from being converted to a Unix domain socket if this is set. This is useful to exempt specific sockets from being matched when another rule matches a broad scope.

These options are available:

addr[ess]=ADDRESS

The IP address to match, which can be either an IPv4 or an IPv6 address.

port=PORT[-PORT_END]

UDP or TCP port number which for outgoing connections specifies the target port and for incomping connections the port that the socket is bound to.

If a range is specified by separating two port numbers via -, the given range is matched instead of just a single port. The range is inclusive, so if 2000-3000 is specified, both port 2000 and port 3000 are matched as well.

path=SOCKET_PATH

The path to the socket file to either bind or connect to.

Placeholders are allowed here and are substituted accordingly:

%p	port number or `unknown` if not an IP socket
%a	IP address or `unknown` if not an IP socket
%t	socket type (`tcp`, `udp` or `unknown` if it’s neither a stream nor datagram socket)
%%	verbatim `%`

3. Rule matching behaviour

Each rule is matched in the specified order and the first socket (regardless of specificity) that matches is either turned into a Unix domain socket, blackholed, rejected or ignored depending on the action specified.

If a listening socket is matched by the same rule multiple times, subsequent sockets are automatically blackholed (that is, deactivated without the application noticing). The reason for doing this is that it requires fewer rules for common things, such as for example handling services that bind to both IPv4 and IPv6 addresses.

Let’s say we have someprogram, which binds to 127.0.0.1:1234 and [::1]:1234 in that order. All we need to do here is match on port 1234 and only the first (127.0.0.1:1234) socket will actually bind to /foo/bar, the second ([::1]:1234) will be blackholed and is not reachable:

$ ip2unix -r in,port=1234,path=/foo/bar someprogram

Note that this is only the case if both end up using the same socket path. If instead something like this is used, none of the two sockets is blackholed:

$ ip2unix -r in,port=1234,path=/foo/bar-%a someprogram

This will result in two sockets:

/foo/bar-127.0.0.1 for the socket originally binding to 127.0.0.1:1234.
/foo/bar-::1 for the socket originally binding to [::1]:1234.

The reason we blackhole subsequent sockets that lead to the same part is to make the common case less verbose to express.

If we would not blackhole the socket and the matcher would simply fall through to the next rule, the following would be required to achieve the same behaviour that we have in the first example:

$ ip2unix -r in,port=1234,path=/foo/bar -r in,port=1234,blackhole someprogram

4. Examples

4.1. Simple HTTP client/server

The following command spawns a small test web server listening on /tmp/test.socket:

$ ip2unix -r in,path=/tmp/test.socket python3 -m http.server 8000

This connects to the above test server listening on /tmp/test.socket and should show a directory listing:

$ ip2unix -r out,path=/tmp/test.socket curl http://1.2.3.4/

4.2. More complicated example

For example the following could be put into a file given by the -f command line argument:

out,port=53,ignore
out,tcp,path=/run/some.socket
in,addr=1.2.3.4,path=/run/another.socket
in,port=80,address=abcd::1,blackhole
in,port=80,reject=EADDRINUSE
in,tcp,port=22,systemd=ssh

Each line corresponds to a single rule, that is processed in order of appearance and the above example would result in the following:

All outgoing connections to port 53 (no matter if it’s TCP or UDP) will not be converted into Unix domain sockets.
This rule will redirect all TCP connections except to port 53 (see above) to use the Unix domain socket at /run/some.socket.
Matches the socket that listens to any port on the IPv4 address 1.2.3.4 and instead binds it to the Unix domain socket at /run/another.socket.
The application may bind to the IPv6 address abcd::1 on port 80 but it will not receive any connections, because no socket path exists.
Trying to bind to port 80 on addresses other than abcd::1 will result in an EADDRINUSE error.
Will prevent the TCP socket that would listen on port 22 to not listen at all and instead use the systemd-provided file descriptor named ssh for operations like accept(2).

The same can be achieved solely using -r commandline arguments:

$ ip2unix -r out,port=53,ignore \
          -r out,tcp,path=/run/some.socket \
          -r in,addr=1.2.3.4,path=/run/another.socket \
          -r in,port=80,address=abcd::1,blackhole \
          -r in,port=80,reject=EADDRINUSE \
          -r in,tcp,port=22,systemd=ssh

5. Limitations

The program uses LD_PRELOAD (ld.so(8)), so it will only work with programs that are dynamically linked against the C library. Using ip2unix on statically linked executables or on executables that don’t use the socket family functions of the C library (like Go programs) will not work at the moment.
If a client which is already using Unix datagram sockets sends packets via sendto or sendmsg to a socket provided by ip2unix without binding first, ip2unix is not able to identify the peer and will subsequently reject the packet. This is not the case when using ip2unix itself on the the client side and it also does not seem to be very common as the author so far did not find such an application in the wild.

However, if this really is an issue to you, the recommended workaround is either to use ip2unix to wrap the client (if it supports IP sockets) or fix the server to natively use Unix domain sockets.

6. Frequently Asked Questions

6.1. Isn’t this functionality already covered by socat?

The socat tool has a very different purpose: It is essentially a way of connecting streams between different address types. Apart from a myriad of options, it supports quite a lot of address types and it’s really good at providing great flexibility to connect bidirectional streams.

However what it doesn’t do is change the behaviour of the target application, which is what ip2unix does.

For example, if you have an application that listens to TCP port 1234, you can use socat to create a Unix domain socket listening on foo.sock and proxying all requests to TCP port 1234:

$ socat UNIX-LISTEN:foo.sock,fork TCP:localhost:1234

Here, the application will still listen to TCP port 1234, but we now have two additional sockets (Unix inbound and TCP/IP outbound) we need to take care of.

ip2unix on the other side redirects the C library calls of the application in question, so that TCP port 1234 will not be bound in the first place and instead the application directly binds to a Unix domain socket.

This not only allows for better privilege separation (because local users need file system access permissions to the socket file) but also involves less overhead since only one socket (the listening socket of the application itself) is used.

6.2. Yes, but can’t this still be done via socat and the iptables owner module?

Of course you could use iptables to only allow access to the user running socat. But again, this still needs additional sockets and also still doesn’t decrease the attack surface by a large margin (eg. there could be race conditions in loading iptables rules or simply human error specifying the rules).

Not binding to an IP socket in the first place however gets rid of that attack surface, since you can’t attack things that don’t exist.

7. Similar projects

socket_wrapper: The goal is a different one here and its main use is testing. Instead of using rules, socket_wrapper turns all of the IP sockets into Unix sockets and uses a central directory to do the mapping.

Containing all Unix sockets into one directory has the nice effect that it is easy to map any address/port combination to Unix sockets. While this is way easier to implement than our approach it has the drawback that everything is contained and no IP communication is possible anymore.
force-bind-seccomp: Very similar in nature but instead of focusing on Unix domain sockets it allows to replace bind arguments for IP sockets. Unlike ip2unix however, it uses seccomp BPF in conjunction with ptrace, so it’s much more effective if you have to deal eg. with a statically linked program (see Limitations above).

The rule matching syntax also is very similar and it also has a way to force programs to use systemd socket activation. If Unix domain sockets are not what you want, you might want to give it a try.

8. Thanks

Special thanks to the NLnet foundation for sponsoring the initial work on this project.

9. Copyright

This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

nixcloud/ip2unix

nixcloud

Reviews

Repository Details