[libvirt] "migration_address must not be the address of the local machine: 127.0.0.1"
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? This comes from: commit 5e0561e115de10da342296bb7c7361e91e368d9c Author: Chen Fan <chen.fan.fnst@cn.fujitsu.com> Date: Tue Oct 7 12:07:32 2014 +0800 conf: Check whether migration_address is localhost When enabling the migration_address option, by default it is set to "127.0.0.1", but it's not a valid address for migration. so we should add verification and set the default migration_address to "0.0.0.0". Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com> Signed-off-by: Ján Tomko <jtomko@redhat.com> I checked the mailing list archive. AFAICS, the earliest appearance of this check is: https://www.redhat.com/archives/libvir-list/2014-August/msg01503.html The validity of the proposed check was never questioned, nor explained. What gives? 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). If there's a way to disable incoming migration in libvirtd, I'd be interested in that. Thanks! Laszlo
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 -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
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.
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
I agree about that. Thanks Laszlo
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 -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 11/25/15 12:10, Daniel P. Berrange wrote:
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.
Ah, great. Jirka said the same. Thank you both. Cheers Laszlo
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
On Wed, Nov 25, 2015 at 12:07:00 +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.
There will be no listener unless you start migrating to your host. Jirka
participants (3)
-
Daniel P. Berrange -
Jiri Denemark -
Laszlo Ersek