tim-seoss commented 4 years ago

Required information

Distribution: Ubuntu
Distribution version: 20.04
The output of "lxc info" or if that fails:
- Kernel version: 5.4
- LXC version: 4.0.1
- LXD version: 4.0.1
- Storage backend in use: dir

Issue description

LXD does not currently permit the following settings to be set on container network devices which are attached to unmanaged bridges.

I’m trying to achieve the following configuration:

Bridged networking on the lxd host.
External router (the lxd host should not NAT this network itself - the external router could be either NATed, or non-NATed - this varies between containers and NICs).
IP addresses (and gateways, and DNS etc.) statically assigned to the lxd host.
IP addresses (etc. as above) either configured as static IP addresses within each container, or via DHCP (either the lxd host, or an external DHCP server could provide this to the containers).
Filtering configured on the lxd host, so that it’s not possible for root users within containers to reconfigure the container’s network to successfully spoof the IP address or mac address of another device attached to the bridge network.

This works and is straightforward to implement in all respects, except the IP spoofing prevention.

Currently if I try to set this up with an unmanaged bridge (managed by the usual OS means - e.g. netplan) I can setup the following configuration:

lxc config device add c1 eth1 nic name=eth1 nictype=bridged parent=br1 lxc config device set c1 eth1 ipv4.address 10.42.42.42 lxc config device set c1 eth1 security.mac_filtering=true

but extend it like this:

lxc config device set c1 eth1 security.ipv4_filtering=true lxc config device set c1 eth1 security.ipv6_filtering=true

… so I can’t guard against IP address spoofing (arp spoofing for ipv4 or NDP spoofing for ipv6) by an attacker which gains control of a container, unless I set up some mechanism external to LXD to accomplish this (e.g. trying to discover the container's corresponding veth devices on the LXD host, and then applying filtering rules there) - which just feels messy (especially since LXD already supports this for managed bridges).

I may be missing something, but I can't see an obvious reason that this would not be possible to implement for unmanaged bridges in a similar way to the existing fictionality for managed bridges.

stgraber commented 4 years ago

For this feature to work we need to know the IPv4 and IPv6 addresses ahead of time.

That's pretty easy when we manage the bridge but quite a bit harder when we don't.

Do all your containers have an ipv4.address and/or ipv6.address set to the value they'll get from your external gateway/DHCP?

If they do, it may be possible to support but if they don't it having to set them all like that by hand isn't an option for you then unfortunately there's nothing we can do.

tim-seoss commented 4 years ago

Hi @stgraber Thanks for your comments.

In my situation, I think it's reasonable to tell LXD about the IP addresses which should be used in the filtering rules e.g. like this:

lxc config device set c1 eth1 ipv4.address 10.42.42.42
lxc config device set c1 eth1 ipv6.address 2001:DB8:cafe:1::1
lxc config device set c1 eth1 security.mac_filtering=true
lxc config device set c1 eth1 security.ipv4_filtering=true
lxc config device set c1 eth1 security.ipv6_filtering=true

As you say, this will require something external to lxd to ensure the correct IP is configured within the container. In my case, I statically assign the same IP address within the container using ansible ( using the lxd ansible transport to get out-of-band access).

It might also be reasonable to use an external DHCP server to configure the containers with the same IPs that the containers have in their ipv?.address configuration.

Taking care of the IP assignment outside of LXD seems like a much easier (and less hacky) solution, compared to setting up extra filtering rules (outside of LXD) on the set of network interfaces that LXD has set up on the LXD host...

stgraber commented 4 years ago

@tomponline given this, is it easy to relax the check?

tomponline commented 4 years ago

@stgraber I think its doable, just need to take a bit of time to look through the code and make sure nothing is depending on dnsmasq that cant be tweaked to remove the dependency.

tomponline commented 4 years ago

@stgraber have added to ideas board.