On Sat, Feb 07, 2009 at 12:44:07AM +0000, David Lutterkort wrote: > On Fri, 2009-02-06 at 13:36 -0500, Karl Wirth wrote: > > What if we could flexibly change the iptables rules for the different > > guests as they are deployed onto the node/host. The idea would be to do > > all of this within the iptables of the host leaving alone the iptables > > of the guests themselves. > > The first issue with this is that the host does not know the IP > addresses in use by the guests; it might be possible to work around that > with setting up rules matching on bridge ports in some cases. Actually I believe Karl's use case is that the host explicitly *does* know the IP the guest is /supposed/ to be using, and wants to prevent it spoofing someone else's IP. > Secondly, network devices may be directly assigned to guests - in that > case, we won't even see any of the packets the guest sends or receives. I think that's a tradeoff you decide to make when assigning the NIC directly, so we can just declare it out of scope. > I also don't see how you can implement that in the general case, given > what a management nightmare iptables is. The trouble is that in a > general libvirt installation, we could have arbitrary iptables rules in > effect that are not controlled by libvirt. To reliably say, for example, > that we reliably block all ports for VM x, we'd either need to > understand all the existing iptables rules, or insert our rules first in > the appropriate chains and be confident that they will never conflict > with any other manually set up rules. It is tricky, but I don't think it is any worse than the situation we are already in WRT to iptables usage by the virtual networking stuff. We're basically talking about adding deny rules against the TAP device associated with the guest. The complexity comes because a user might add further rules which then allow stuff we denied, or apps / commands may flush rules we've added. I think it is fine to just document the limitations / requirements in this case. > It would be nice to do this, to offer an additional layer of security, > especially around insecure OS's; to pull that off in practice, you'd > need to assume fairly tight control of the host (e.g., only use shared > network interfaces, only deal with iptables rules set up by a known > application) > > With that, iptables management belongs into a higher-level management > app, like ovirt, not libvirt. NB, we do already have indirect iptables anti-spoofing support for the Xen driver in libvirt. If you specify a <ip address> tag for a Xen bridged network driver, the vif-bridge script will try to add rules to prevent the vnet device using a different IP address. I agree with your general point though, that when trying this in a general purpose OS deployment I don't think you can provide sufficient guarentees from a libvirt POV. There are simply too many other things that may break or otherwise badly interact with the iptables rules we're adding. At the very simplest level, 'service iptables restart' messes things up. In the context of a controlled host image, like the oVirt managed node, the mgmt app is in control of the host OS, and in such a scenario it may be practical for libvirt to add iptables rules for guests. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list