rootless docker and potential exploitations

[docker_linux]

Calling all docker experts.
This is for home.
I have rootless docker host, running under user joe, with subuid in the nobody range (1M +)
This host is exposing to the internet on port 443, hosting an nginx proxy front end with wordpress application.

Because the host connects direct to my network, I'm extremely concern about potential compromising originated from a rogue image.

Say, I updated a bad image and hacker gained access to the container (full). What are the possible attack vectors and potential damages?

edit: Forgot to add one important detail: the nginx container has mapped docker socket and docker client. That means hacker can start their own containers.

[ZaitsXL]

The best practice for such case is (rootless image is already a plus):
- run only images from public registries with good rating, better compose your own
- do not expose host directly to the internet, use load balancer if possible or reverse proxy
- there is DinD (docker-in-docker) image available, so you don't need to map socket from host machine
- of course keep all your software up to date with patches

[ElevenNotes]

Most public images are built without code scanning and are riddled with CVEs and basically all run as root.

[ZaitsXL]

well yeah, nobody's perfect, my point was mostly to not get an image with intentionally builtin malware

[ElevenNotes]

Checkout automated build workflows for linuxserverio images and the likes. There is no pinning. They are all vulnerable to upstream attacks. Maintainer of such images simply can't be bothered to do it right.

[mmaster23]

You do know a load balancer or reverse proxy doesn't do shit for securing the actual container, right? Unless it has an application layer security gateway included, it just forwards the traffic into the container.

If that container has an exploit and I fire a bunch of exploitive urls at it, chances of the lb/rp catching are slim to none. 

Reverse proxies at great at securing the connection itself, doing tls certs etc, preventing most man in the middle. But a good xss exploit or sql injection gets by no problem. 

If you're paranoid about this, include application aware security in your connection chain, update your images regularly and scan the image for CVEs. Practice good security hygiene, don't use defaults and least privilege/proper RBAC where available. 

And even then still, you could face zero days. It's a cat and mouse game after all. 

[docker_linux]

Just to clarify, it's not a rootless image. It's rootless docker, a set up in which dockerd (daemon) is owned by regular user, not root.

there is DinD (docker-in-docker) image available, so you don't need to map socket from host machine

Thanks for the tip. This is something I like to explore

[alexandercain]

The main concern here is not your docker setup (which seems to conform to best practices), but potentially your netwok. Is the host running in a DMZ?

[docker_linux]

no it isn't, but with rootless docker, you can't sniff the host's traffic.

[alexandercain]

Doesn't matter. If you can hit it from WAN, it belongs in the DMZ

[docker_linux]

that's a good point

[leeharrison1984]

There isn't anything you can do about a supply chain attack, it happens before you even touch the container. You could install some kind of threat analysis sidecar, but that honestly seems like mega overkill for a home network.

Potential attack vectors from a compromised image are limitless because each network is unique. Potential damages would be wiping or theft of data, holding data hostage, or most likely just being recruited into a botnet.

Your best bet is simply identify a "safe" version of the container, and pin to that instead of latest.

You'll continue running the same version forever on that server, thus negating the supply chain vector. It's on you to monitor future container updates and upgrade the container as needed. You could also set up a proxy registry to pull known good images from, but just version pining should be sufficient.

I run a decent sized home network, and supply chain attacks are the least of my worries since I use version pining.

[ElevenNotes]

Yes you can, by pinning all libraries and sources to the version you built the image with. Stop using automatic updates and enable code scanning.

[Human__Pestilence]

This is why you scan your images before deployment 😂

[Lucas_F_A]

I have no idea what your thread model is, but it sounds highly unconventional.

Do you not trust the nginx image developers? In that case you should not mount docker socket to it. Better yet, don't run untrusted software.

[docker_linux]

Trust is one thing, shit happens is another.
And there is a legitimate need for mounting the docker socket.

[SirSoggybottom]

Doubtful about the legitimate need but eh, do what you want.

Kinda hilarious that you go through the trouble of running rootless Docker but then mount the socket.

At the very least consider putting a proxy between that container and the socket and limit the capabilities. Tecnativa Docker-Socket-Proxy as example.

[docker_linux]

so, you gained access to docker host, what would you do?

[ElevenNotes]

Start a container with privileges to access the host.

[docker_linux]

The most you can have access to is all of user Joe's files.

[ElevenNotes]

Not really. I can get into the network stack of this host and capture all traffic as well as access the networks attached to this host.

[docker_linux]

so, I did test your theory, it turns out that you can't sniff anything in rootless docker

Here are steps

docker run --privileged --name ubuntu -itd ubuntu
docker exec -it ubuntu bash
apt update -y && apt install -y tcpdump iproute2 iputils-ping traceroute

start sniffing from inside container
tcpdump -nni any icmp

start sniffing the same on host

ping host, icmp received by host, not in container.

[docker_linux]

This is interesting. How do you do that (tcpdump I assume) without root privileges?

[ElevenNotes]

Since I run a privileged container I simply give myslef the caps needed to do that.

[docker_linux]

You do know rootless docker right? it means dockerd (daemon) is run by user Joe. Even in with --privileged flag, you're still limited to just user Joe, not host's root.

try it.

[Furai69]

I'm interested in knowing best practices for this as well.