[BUG] Host is forced to :: / 0.0.0.0 -- security vulnerability

[tubededentifrice]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

At https://github.com/linuxserver/docker-sabnzbd/blob/master/root/etc/s6-overlay/s6-rc.d/svc-sabnzbd/run#L4 the host is forced to "::" or "0.0.0.0" (depending on IPv6 availability), preventing the user to binding it only on a single IP (eg. 127.0.0.1)

Expected Behavior

I'm not sure what's the default, but it should only be set like this when there is no existing config file (or at least, make it configurable as an environment variable).

Steps To Reproduce

Try changing SABnzbd Host on the config page, after restarting it's back to "::"

Environment

- OS: n/a
- How docker service was installed: n/a

CPU architecture

x86-64

Docker creation

n/a

Container logs

n/a

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[aptalca]

That's the intended behavior.

You haven't specified what it is you would change it to (or what exactly makes you think there would be a security vulnerabiility), but if you're trying to change it to 127.0.0.1, good thing we don't allow it, because you would lock yourself out of the gui as any connection from outside the container would be rejected (it would bind to localhost inside the container only).

You can control the listen ip as part of the port mapping (ie. -p 127.0.0.1:8080:8080 would make sab listen on the host's localhost only). Better yet, we recommend not even mapping a port and reverse proxying over the docker network with a solution like SWAG.

[tubededentifrice]

That's the whole point of making it user configurable -- so I can bind a reverse proxy that does authentication for SSO in front of it, and having the whole thing otherwise hidden from the outside world (using the reverse proxy's net, with --net=container:reverse_proxy_container). I'm gonna try the port thing, I didn't know that would work.

[aptalca]

put the reverse proxy and sab in the same user defined bridge network and use the address http://sabnzbd:8080 in your reverse proxy
no need to have sab use the reverse proxy's network

EDIT: and don't map any ports for sab as no connection will be made over the host. The connection will go through the docker network that only your reverse proxy and sab will have access to

[tubededentifrice]

Sure... but there is no reason not to make that configurable directly and force it, when it's actually supposed to be user configurable, like every other app

[aptalca]

Letting users do crazy weird things leads to a lot more support requests for us. That's work.

[aptalca]

when it's actually supposed to be user configurable

when you run it on bare metal, sure. That's not what we're doing here

[tubededentifrice]

I think the port mapping trick from above (-p 127.0.0.1:8080:8080) only works when running on host's network, right?
I still think it's neither crazy nor weird, all *arrs allows that to be set, but it sure should default to the current value, listening to everything.

I guess the only option left if it's not made configurable one way or another is to make a docker network for this, although I'm not entirely certain how it will play out with other containers and how I can tweak the isolation:

• Container PROXY is the reverse proxy, it needs to have access to containers SAB, R and C
• C should not have access to things exposed by SAB and R (which have no authentication, since PROXY is doing SSO), as C is considered relatively insecure, and is itself using another container for VPN
• Nothing else should have access to those, no port should be open to the outside world

So right now, I would bind SAB and R onto PROXY's network, listening on 127.0.0.1.
And I have a network that hosts PROXY, SAB, R, C, providing global isolation.

=> If SAB is put on the same network, but not bound to 127.0.0.1, C will have access to it, unauthenticated
=> If I create another network to put C, then I don't think PROXY will be able to reach it (or C will be able to reach SAB)

[tubededentifrice]

(for reference, ich777 does it right: https://github.com/ich777/docker-sabnzbd/blob/master/scripts/start-server.sh#L62 )

[aptalca]

I think the port mapping trick from above (-p 127.0.0.1:8080:8080) only works when running on host's network, right?

No. It's so that the app's port is accessible from the host while the container is in a bridge network.

Forget about binding to 127.0.01. They are containers and they are isolated by default in bridge networks. In a bridge network, listening on 127.0.0.1 means only listening for connections from inside the container.

You're overthinking it. Read up on user defined bridge network. Two containers attached to the same user defined bridge network can resolve each other by container name, and can connect over that docker network. You can attach a container to many networks.

Put SWAG and sab on network A
Put SWAG and radarr on network B

SWAG can connect to both sab and radarr via their container name and container port, but sab and radarr can't connect to each other.

Here's the SWAG docs on that subject: https://docs.linuxserver.io/general/swag/#docker-networking

[tubededentifrice]

Oh gosh, that's the point I was missing: a container can attach to multiple networks! I guess that would indeed solve it. Let me try that. Many thanks.

[tubededentifrice]

So... I played with it, and solution isn't perfect, as bridge networks needs to go through default route (ie. I can't bind them to a VLAN -- I somehow don't want the containers to be able to reach the host -- Unraid in my case -- or other parts of the network). In ipvlan/macvlan, I'd need to create separate VLANs for each isolation at the router level.
I think my best bet would be to go through the host route as you suggested, but finding a way to route through the correct interface (user script or something) -- which overall makes stuff a lot more complicated than just binding to 127.0.0.1.

Edit: I've made a docker mod to bypass, until I have a better solution: https://github.com/tubededentifrice/docker-mods / https://hub.docker.com/repository/docker/tubededentifrice/mods/general

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.