ryanlovett / portwrap

Sandbox for exposing one host port

portwrap

portwrap launches a specified program into a user and network namespace. It routes traffic to the program from a host port to the namespace's guest port. If other programs are started in the namespace, their open ports will only be accessible to the namespace and not to the host.

This might be useful if the program it launches knows how to proxy traffic to other programs in the namespace.

portwrap is a python script that calls slirp4netns and bubblewrap (bwrap).

Preparation

1. The administrator must configure subuid/subgid mapping.
2. Install slirp4netns and bubblewrap.

Installation

pip install git+https://github.com/ryanlovett/portwrap

Usage

% portwrap --help
usage: Usage: portwrap [-h] -p HOST_PORT -P GUEST_PORT COMMAND [COMMAND ...]


optional arguments:
  -h, --help            show this help message and exit
  -p HOST_PORT, --host-port HOST_PORT
                        Host-accessible port
  -P GUEST_PORT, --guest-port GUEST_PORT
                        Namespace-accessible port

If COMMAND uses an argument to set a listening port, you can specify the template string {guest-port} instead, and portwrap will substitute the value of GUEST_PORT.

Examples

1. Start JupyterLab on the host port 9876. Note that use of the template string {guest-port} below is literal -- you don't substitute anything for it.

% portwrap -p 9876 -P 8888 jupyter lab --port={guest-port} --ip=0.0.0.0 --no-browser

Within the user/network namespace, jupyter will be listening on port 8888. If jupyter-server-proxy is installed, its proxied services will be sandboxed by the namespaces and will be reachable by jupyter_server, but not by other processes on the host.

portwrap's Issues

Make sure root UID/GID are mapped properly

I've discovered that UID 0 / GID 0 is being mapped to 65534 on a local system in a server spawned with portwrap. This was flagged when a user attempted to use git/ssh from this jupyter server, and ssh complained that a file in /etc/ssh/ssh_config.d/ had the wrong permissions. They are 65534:65534 within the user namespace and 0:0 on the host. I suspect this is happening because of how subuid/subgid are configured on the system, but I need to test.

DNS issues with systemd-resolved

I discovered a problem on one of our Ubuntu systems running systemd-resolved. The wrapped jupyterhub-singleuser process was trying to request {hub_url}/hub/api, but couldn't because the hostname of the hub wouldn't resolve. All of our other systems were fine.

On the affected machine, I could not host {hub_hostname} nor curl {hub_url}/hub/api.
On an unaffected machine, I could not host {hub_hostname}, but I could run curl {hub_url}/hub/api.

It turns out that nscd was not running on the affected machine. When a process tries to make direct DNS queries to 127.0.0.53 they cannot, but nscd essentially proxies name service requests through the socket at /var/run/nscd/socket.

I need to figure out how to address the case where the host system is running systemd-resolved and not nscd.

Replace sh with initial command

portwrap starts sh in the namespace created by bwrap. This was an easy method to return the PID of the namespaced process. It'd be better if portwrap could run the specified command in the namespace from the start, without having sh sleep in a loop. This would help with shutting down the process and namespace. I'm not sure how to get bwrap to return this information however, without using some other process that exists to return its own PID, and then perhaps gets displaced by portwrap's initial command.

Clarify preparation step 1

Hi Ryan,

First thank you for portwrap, it is exactly what we have been looking for to isolate users' jupyter proxy servers on our clusters for a loooong time.

I was able to install bubblewrap, slirp4netns and portwrap all in user space and make it works on our production clusters. Which brings me to a question: I haven't done anything related to uid / gid mapping, nor the administrator did. Am I missing something or is that step optional? The rootless containers documentation is a bit vague on when it is actually required.

Thanks again!

EDIT:
My tests were done with

• Rocky 8.7 - kernel 4.18.0-425.10.1.el8_7.x86_64
• bubblewrap 0.4.0
• slirp4netns 1.2.0

Clean up slirp4netns processes

Terminate slirp4netns before we exit. We may have to trap signals.

Clean up sh and sleep loops

When portwrap's command stops, the initial sh command lingers, as does the sleep loops. These need to be terminated properly.