I'm afraid my initiation to ebtables (and iptables) was yesterday, so feedback such as this is highly appreciated. I will explore this and add a test to the repo.
> I guess it's not clear to me if the vulnerability/bug/whatever here is "two conspiring containers can establish a covert channel" or "a malicious container can send normal-looking traffic to a container, bypassing that container's firewall rules."
In the context of a sandbox, I purport the vulnerability is that a malicious container can bypass the firewall. The covert channel is largely inevitable because ultimately the containers can modulate cpu usage to communicate via cpu timing (I read this in a security paper somewhere, not sure how actual implementation works).
The impact of bypassing the firewall can be serious if the non-malicious container exposes any service without proper authentication (as is often done behind VPCs in the cloud).
Given that a high number of official containers contain known vulnerabilities (according to dockerhub). This is a potential issue for a large number of docker users.
> It does seem like the right answer is unique bridge networks per container.
My thinking is along the same lines, although I'm wondering if a container can communicate with the host if L2 packets may be able to traverse the network bridges. If anyone has input here, it'd be greatly appreciated.
You can use the iptables physdev extension to match based on a bridge port rather than a mac address.
So to filter between containers, you can do:
iptables -I FORWARD -m physdev --physdev-in vetha056126 -j DROP
The iptables filter table has three chains: INPUT, OUTPUT, FORWARD. In a traditional non-bridge context:
- INPUT means packets entering the host
- OUTPUT means packets leaving the host
- FORWARD means packets being forwarded through the host which are not destined for the host itself.
In the context of a bridge, FORWARD means forwarding packets from one bridge port to another. You can test the simplest case of this with:
iptables -I FORWARD -j DROP
ebtables supports «broadcast» as a destination to match ethernet frames on.
ebtables … -d broadcast
ebtables … -d ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ffBoth are part of the netfilter subsystem in the linux kernel.
I have a friend that I worked with at now large company (now) with back in the startup days. Guy worked at ATT and has name on RFCs for things that make all this stuff work. We where doing the startup thing, ie the guys that understand it own it, for the company. No IT so you do it since you know it...firewall and vpn, etc (he wrote routing code, I was CSE), but startup so... It made me laugh so hard when he said “iptables makes no sense. Black magic. Let’s just use PFsense”. That had always been my view but to hear someone that wrote the stuff that makes this Internet magic work agree with me was joyful.
I guess it's not clear to me if the vulnerability/bug/whatever here is "two conspiring containers can establish a covert channel" or "a malicious container can send normal-looking traffic to a container, bypassing that container's firewall rules."
It does seem like the right answer is unique bridge networks per container. On physical networks, it's hard to prevent two untrusted devices on the same L2 domain from establishing a covert channel. (And it's hard to prevent two networked untrusted, conspiring devices anywhere on the internet from establishing a covert channel, if they're trying hard enough.)