⚠️ Security Update in v2024.01.08.1431

Announcements
#21

While properly supported Docker distributions do not have the iptables bug, and therefore does not get mitigated by our patch, and THEREFOR doesn't have local auth disrupted, you may see 403 connection errors with inter-dvr communications when they're all running on the same Docker host.

In these cases, you should use the container name and port 8089 in place of host IP and custom port, when referencing them.

For example, you may have 2 instances of Channels DVR Server running under Docker all in bridged mode with their own ports. Maybe you employ some tricks to have them talk to each other to create Custom Channels or other shenanigans. You'll find that when they talk to each other, they will be prompted for authentication.

To resolve this, use the container name with port 8089 instead of the IP of the host and custom port.

So instead of using:

http://192.168.0.122:8070/devices/TVE-Provider/channels.m3u?format=ts

to talk to another instance of Channels DVR Server, use:

http://another-channels-server:8089/devices/TVE-Provider/channels.m3u?format=ts

3 Likes
#22
#23
#24

Were you able to identify in which version of Docker this was fixed?

I know the latest Container Manager Package v20.10.23-1437 for Synology is affected, running docker engine v20.10.23. Would like to ask Synology for an updated version, but don't know which newer version has the fix.

I'm not a developer, but there are lots of release notes at the Moby project, including my version.

#25

I don't believe this is an issue with Docker. I believe it's an issue with the OS distribution (the custom distribution that Synology ships) not providing all of the hooks/packages/binaries that Docker needs to do the configuration that it needs to do by default. This could be an issue with the general security stuff that Synology does is interfering with the normal operation of Docker, or could be some missing packages or binaries.

Honestly these are all just guesses and would really require Synology to put engineering resources into looking into what's going on here to get to the bottom of it. If someone would want to engage with Synology to get that to happen, that would be great for the community as a whole.

#26

So this is just an issue on Synology (and their crappy crippled OS)?

#27

That is my best guess.

#28

Hi folks, Thanks for all your work keeping Channels secure and safe.

I run Channels in Docker on Mac in bridge network mode, and I'm now unable to access my server locally without authentication. Docker for Mac does not support host mode, so that is not an option for me. I've made sure I'm on the latest docker and channels container image.

Is it possible to add a setting to turn this authentication requirement off (for we people who know what we're doing to use) or to add an IP range we want to treat as local traffic? (Does such a setting perhaps already exist?)

1 Like
#29

Couple things:

  1. Could you submit diagnostics so we can see what you’re seeing?
  2. Have you considered running Channels on your Mac directly? It’s going to be a lot more efficient, work better at transcoding (if you use that) and better with TVE (if you use that) on top of just not having to deal with a virtualization layer.

I run my DVR on a Mac Mini and it works really great.

I’m trying to understand the current state of Docker on the Mac and from my googling so far it does appear that NAT should be working properly so you shouldn’t be running into this…

#30

I'm not fully certain what Docker does, but on both Windows and Mac Podman creates a separate Linux VM and runs the container in that VM. Docker on Windows does similar through WSL2, so I imagine their engine uses a Linux VM on the Mac, too.

#31

I'm aware of the tradeoffs of using docker on mac, but I much prefer managing my services with docker than trying to run everything native. I recognize this is not a preferred configuration for the project and understand if you don't want to fix this edge case.

AFAIK racameron is correct about how docker functions on mac, although newer versions do use the new macOS virtualization framework and I don't know how that affected things.

I've submitted diagnostics as d0c0d0f1-4e2a-4c7e-af56-15b0b04a5eac

#32

@robotmlg I've run some tests with traefik/whoami on my Docker Desktop setup on my Mac and as far as I can see there isn't a way to get it to do any sort of NAT to those guest. Because of that it appears to be impossible to properly secure this kind of installation and so at this point it looks like it's not going to be a configuration that we can support.

Looking at your diagnostics, it does appear you setup port forwarding and exposed the container to the internet, at which time it identified that the network configuration was allowing anyone on the internet unrestricted access to the container and shut down unauthenticated access from that proxy IP (the docker proxy IP).

I know this sucks, but at this time the only options I know of for you are going to be to move this to your Mac host or move to Docker on a Linux system. Sorry I don't have better news.

#33

Thanks so much for investigating, Eric. I’m just glad to know this is docker doing weird things and not me.

1 Like
#34

Thanks. Unfortunately I screwed something up and had to move this particular installation out of docker and onto a spare Synology machine. Everything seems to be working correctly now.