On Fri, Feb 07, 2025 at 06:39:50AM -0800, Andrea Bolognani wrote: > On Fri, Feb 07, 2025 at 11:09:35AM +0000, Daniel P. Berrangé wrote: > > On Thu, Jan 30, 2025 at 12:47:41PM -0800, Andrea Bolognani wrote: > > > If things really work the way you describe them, it sounds like an > > > unsolvable problem indeed. Any scenario in which all possible > > > components need to be aware of each other obviously doesn't scale. > > > > That's not quite the case. libvirt shouldn't need to know about docker, > > and vica-verca. docker & libvirt both need to know about the base > > OS' choice of firewall mgmt tool (ufw, firewalld, initscripts, etc) > > and support whichever the base OS has used. A decent number of > > variations, but not a combinatorial expansion at least. > > If we can restrict the number of external components that we have to > be mindful of to just firewall implementations, then things don't > sound quite as bleak. Still quite a lot of work ahead. > > I'm wondering though, are we sure that e.g. Docker is doing the same > thing? My understanding is that if we go through firewalld but they > still add rules directly then we're screwed regardless. Yes, we can't solve it alone, if other apps still use direct rules, *and* their direct rules are applying broad DROP/REJECT rules. I don't know what docker adds, but if they're similar to libvirt their rules would be merely about opening holes, or restricting traffic on their own managed bridges, rather than blocking traffic broadly. In that case, docker would still be doomed by not using firewalld directly, but libvirt would be OK. > > > Have the nftables maintainers expressed their opinion about this? > > > Surely they would have considered how to make filtering work without > > > forcing extremely tight coupling. > > > > Usage is a decision for userspace and I believe the firewalld > > maintainers would expect everyone to directly use firewalld's > > APIs to achieve their goals and not go behind its back with > > native calls. > > So the nftables design basically demands that an additional layer is > added on top? IMHO that's unavoidable no matter what firewall technology is present in the kernel, because part of libvirt's need is to allow holes in a few places which are outside its own created bridge device. > > > I'll note that the nwfilter driver not having an nftables backend is > > > another, if secondary, reason to stick with iptables by default. The > > > main goal for most people is to create a deployment that's completely > > > free of the legacy userspace, and if some other driver is going to > > > drag it in anyway, a big part of the benefit is immediately lost... > > > > The nwfilter driver is not a big deal as its firewall rules are entirely > > self-contained and attached to the vnetXXX devices which no other tool > > will be trying to put rules on, so there's no expected clash & I've > > never heard any reported. > > That's not what I meant. Some people are just very eager to not have > iptables installed at all on their machines for whatever reason, and > as long as one of the drivers can only use iptables as the backend > that's much harder to achieve. RPM has choice deps eg "requires: nftables or iptables", but in the end we didn't use that in Fedora - we just left the default choice as the mandatory dep and didn't add a dep for the non-default. Can't quite remeber With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
