canonical / lxd

Powerful system container and virtual machine manager
https://canonical.com/lxd
GNU Affero General Public License v3.0
4.32k stars 926 forks source link

LXC/LXD bridge security clarification #7026

Closed ootohgheth6ehaeY closed 4 years ago

ootohgheth6ehaeY commented 4 years ago

The lxd docs on container security don't mention the bridge at all and link to the LXC security page for more details on container security. On the LXC security page, under shared network bridges, it says: "As a container connected to a bridge can transmit any level 2 traffic that it wishes, it can effectively do MAC or IP spoofing on the bridge." As per this blog post "The default mode is “managed” and is typically the safest and most convenient as it provides DNS records for containers but doesn’t let them spoof each other’s records by sending fake hostnames over DHCP."

Does that mean that thanks to the DNS managed mode a malicious container can't spoof the hostname of another container, but is free to spoof MAC or IP addresses?

As per this post, which links to configuration options that have been moved here, there are the "security.mac_filtering", "security.ipv4_filtering" and "security.ipv6_filtering" flags that default to false and have to be set on a per container basis(?) to prevent spoofing of those.

Also, does anything address the Cross-Container ARP Poisoning issue?

Please clarify the situation in one place. Please also clarify if all the measures one can take can actually be somewhat relied on or if, due to e.g. ARP poisoning, it is still recommended to create a new bridge for each potentially untrusted container. (Encrypting the traffic would probably also suffice?)

stgraber commented 4 years ago

Yeah, managed DNS just means that DNS isn't updated through DHCP leases, so the containers can't mess with it. They can still steal each other's IPs or MACs unless additional configuration is performed.

In LXD, using managed DNS on the bridge, combined with MAC, IPv4 and IPv6 filtering will prevent DNS, MAC and IP spoofing. They do need to be set on the container network devices or through a profile. It's worth noting that those options effectively prevent nested containers, at least nested containers on the same network as their parent.

stgraber commented 4 years ago

@tomponline can you send a PR (against LXD) to cover the network security bits in security.md?

ootohgheth6ehaeY commented 4 years ago

Thanks a lot for the super quick answer! :)