On Wed, Nov 25, 2015 at 11:52:21AM +0100, Laszlo Ersek wrote: > I recently upgraded my laptop from RHEL-7.1 to RHEL-7.2. > > I always pay attention to *.rpmnew config files, and I manually diff and > merge them with the ones I have in place. > > I did the same with "/etc/libvirt/qemu.conf" this time. > > Now libvirtd doesn't start for me. Systemd doesn't actually notice the > startup failure (insert bitter joke about systemd being so much better > than startup scripts); it only reports the service inactive/dead (= > unstarted), rather than failed. > > But, the libvirtd log file gives the reason: > > migration_address must not be the address of the local machine: > 127.0.0.1 > > The error is easy to fix up in the config file, but my question is: > > Why must migration_address not be the address of the local machine? The migration address for incoming migration over TCP needs to be a public facing IP address, otherwise the remote machine won't be able to connect to it. If you configure migration_address on the target machine to be 127.0.0.1, then obviously no migration client connection will ever succeed, hence we consider 127.0.0.1 as an invalid configuration. > BTW, my purpose is not in-host migration (perhaps that's indeed > unsupported, I don't know); I just want to lock down the incoming > migration port (and not just with firewall rules). What's wrong with using firewall rules ? IMHO you are describing exactly the scenario that are intended to deal with.

> If there's a way to disable incoming migration in libvirtd, I'd be > interested in that. You could setup libvirt's API access control rules to deny the "migrate" privilege to all users. Using firewall rules is a more secure solution though IMHO

Regards, Daniel

On Wed, Nov 25, 2015 at 12:07:00PM +0100, Laszlo Ersek wrote: > On 11/25/15 12:00, Daniel P. Berrange wrote: >> On Wed, Nov 25, 2015 at 11:52:21AM +0100, Laszlo Ersek wrote: >>> I recently upgraded my laptop from RHEL-7.1 to RHEL-7.2. >>> >>> I always pay attention to *.rpmnew config files, and I manually diff and >>> merge them with the ones I have in place. >>> >>> I did the same with "/etc/libvirt/qemu.conf" this time. >>> >>> Now libvirtd doesn't start for me. Systemd doesn't actually notice the >>> startup failure (insert bitter joke about systemd being so much better >>> than startup scripts); it only reports the service inactive/dead (= >>> unstarted), rather than failed. >>> >>> But, the libvirtd log file gives the reason: >>> >>> migration_address must not be the address of the local machine: >>> 127.0.0.1 >>> >>> The error is easy to fix up in the config file, but my question is: >>> >>> Why must migration_address not be the address of the local machine? >> >> The migration address for incoming migration over TCP needs to be >> a public facing IP address, otherwise the remote machine won't be >> able to connect to it. If you configure migration_address on the >> target machine to be 127.0.0.1, then obviously no migration client >> connection will ever succeed, hence we consider 127.0.0.1 as an >> invalid configuration. >> >>> BTW, my purpose is not in-host migration (perhaps that's indeed >>> unsupported, I don't know); I just want to lock down the incoming >>> migration port (and not just with firewall rules). >> >> What's wrong with using firewall rules ? IMHO you are describing >> exactly the scenario that are intended to deal with. > > I certainly use firewall rules. > > But, I like to disable listeners, especially public listeners, on the > individual application level too, if I don't have a good use for the > service. NB, nothing will ever listen on the migration_address unless you actually trigger a migration to the host in question.

So if you have authentication required to connect to libvirt you'll be fine unless the person using libvirt asks to migrate a VM to that host. An authenticated connection to libvirt should be considered equivalent to having root access regardless, so from that POV having migrate_address point to a public IP is not opening you up to any attack vector that doesn't also exist when you have it set to 127.0.0.1. So I still think restricting the address to 127.0.0.1 is not adding you any actual security benefit. Regards, Daniel