[libvirt] Question about LSN-2016-0001
I've noticed the behavior described by this LSN with libvirt+Xen. Config containing <graphics type='vnc' passwd=''/> allows any client to connect with no authentication check. I asked about this on the Xen security list and was told that "libxl interprets an empty password in the caller's configuration to mean that passwordless access should be permitted". The libvirt domXML docs are not clear on semantics of empty vnc password, only stating "The passwd attribute provides a VNC password in clear text". Should the libvirt domXML vnc passwd documentation be amended to define the semantics of an empty string in the passwd attribute? Is the behavior hypervisor-dependent as the documentation in qemu.conf suggests? Regards, Jim
On Fri, Jul 29, 2016 at 02:16:16PM -0600, Jim Fehlig wrote:
I've noticed the behavior described by this LSN with libvirt+Xen. Config containing <graphics type='vnc' passwd=''/> allows any client to connect with no authentication check. I asked about this on the Xen security list and was told that "libxl interprets an empty password in the caller's configuration to mean that passwordless access should be permitted". The libvirt domXML docs are not clear on semantics of empty vnc password, only stating "The passwd attribute provides a VNC password in clear text".
Should the libvirt domXML vnc passwd documentation be amended to define the semantics of an empty string in the passwd attribute? Is the behavior hypervisor-dependent as the documentation in qemu.conf suggests?
I guess we've never clarified the semantics in any cross-hypervisor manner. I think the fixed QEMU behaviour is the most sane from a portability POV - the Xen (and broken QEMU) behaviour was effectively overloading 2 settings onto one attribute. ie it was (ab)using a zero length password as a way to change the authentication method. We should always have distinct XML attributes for distinct settings. IOW, any toggle betweeen password and no-auth should an explicit setting and a zero length password should not magically change that. 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 08/01/2016 03:13 AM, Daniel P. Berrange wrote:
I've noticed the behavior described by this LSN with libvirt+Xen. Config containing <graphics type='vnc' passwd=''/> allows any client to connect with no authentication check. I asked about this on the Xen security list and was told that "libxl interprets an empty password in the caller's configuration to mean that passwordless access should be permitted". The libvirt domXML docs are not clear on semantics of empty vnc password, only stating "The passwd attribute provides a VNC password in clear text".
Should the libvirt domXML vnc passwd documentation be amended to define the semantics of an empty string in the passwd attribute? Is the behavior hypervisor-dependent as the documentation in qemu.conf suggests? I guess we've never clarified the semantics in any cross-hypervisor manner. I think the fixed QEMU behaviour is the most sane from a
On Fri, Jul 29, 2016 at 02:16:16PM -0600, Jim Fehlig wrote: portability POV - the Xen (and broken QEMU) behaviour was effectively overloading 2 settings onto one attribute. ie it was (ab)using a zero length password as a way to change the authentication method.
I can't get past thinking the fixed QEMU behavior only changed the overloading of passwd from "disable auth" to "disable vnc access" :-).
We should always have distinct XML attributes for distinct settings. IOW, any toggle betweeen password and no-auth should an explicit setting and a zero length password should not magically change that.
Shouldn't an empty password simply be rejected? I can't set a zero-length password on my UNIX account jfehlig@talkeetna:~> passwd Changing password for jfehlig. (current) UNIX password: New password: <enter> BAD PASSWORD: it is WAY too short passwd: password unchanged jfehlig@talkeetna:~> Regards, Jiim
On Mon, Aug 01, 2016 at 10:00:05AM -0600, Jim Fehlig wrote:
On 08/01/2016 03:13 AM, Daniel P. Berrange wrote:
I've noticed the behavior described by this LSN with libvirt+Xen. Config containing <graphics type='vnc' passwd=''/> allows any client to connect with no authentication check. I asked about this on the Xen security list and was told that "libxl interprets an empty password in the caller's configuration to mean that passwordless access should be permitted". The libvirt domXML docs are not clear on semantics of empty vnc password, only stating "The passwd attribute provides a VNC password in clear text".
Should the libvirt domXML vnc passwd documentation be amended to define the semantics of an empty string in the passwd attribute? Is the behavior hypervisor-dependent as the documentation in qemu.conf suggests? I guess we've never clarified the semantics in any cross-hypervisor manner. I think the fixed QEMU behaviour is the most sane from a
On Fri, Jul 29, 2016 at 02:16:16PM -0600, Jim Fehlig wrote: portability POV - the Xen (and broken QEMU) behaviour was effectively overloading 2 settings onto one attribute. ie it was (ab)using a zero length password as a way to change the authentication method.
I can't get past thinking the fixed QEMU behavior only changed the overloading of passwd from "disable auth" to "disable vnc access" :-).
It is the distinction between what auth method is configured, vs what passwords are valid for the auth method. That an empty password is blocking access is a characteristic of the auth method.
We should always have distinct XML attributes for distinct settings. IOW, any toggle betweeen password and no-auth should an explicit setting and a zero length password should not magically change that.
Shouldn't an empty password simply be rejected? I can't set a zero-length password on my UNIX account
jfehlig@talkeetna:~> passwd Changing password for jfehlig. (current) UNIX password: New password: <enter> BAD PASSWORD: it is WAY too short passwd: password unchanged jfehlig@talkeetna:~>
To start rejecting it now would be a non-backwards compatible change in our behaviour, so we can't really do that. 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 08/01/2016 10:14 AM, Daniel P. Berrange wrote:
On 08/01/2016 03:13 AM, Daniel P. Berrange wrote:
I've noticed the behavior described by this LSN with libvirt+Xen. Config containing <graphics type='vnc' passwd=''/> allows any client to connect with no authentication check. I asked about this on the Xen security list and was told that "libxl interprets an empty password in the caller's configuration to mean that passwordless access should be permitted". The libvirt domXML docs are not clear on semantics of empty vnc password, only stating "The passwd attribute provides a VNC password in clear text".
Should the libvirt domXML vnc passwd documentation be amended to define the semantics of an empty string in the passwd attribute? Is the behavior hypervisor-dependent as the documentation in qemu.conf suggests? I guess we've never clarified the semantics in any cross-hypervisor manner. I think the fixed QEMU behaviour is the most sane from a
On Fri, Jul 29, 2016 at 02:16:16PM -0600, Jim Fehlig wrote: portability POV - the Xen (and broken QEMU) behaviour was effectively overloading 2 settings onto one attribute. ie it was (ab)using a zero length password as a way to change the authentication method. I can't get past thinking the fixed QEMU behavior only changed the overloading of passwd from "disable auth" to "disable vnc access" :-). It is the distinction between what auth method is configured, vs what
On Mon, Aug 01, 2016 at 10:00:05AM -0600, Jim Fehlig wrote: passwords are valid for the auth method. That an empty password is blocking access is a characteristic of the auth method.
I see. Thanks for the explanation.
We should always have distinct XML attributes for distinct settings. IOW, any toggle betweeen password and no-auth should an explicit setting and a zero length password should not magically change that. Shouldn't an empty password simply be rejected? I can't set a zero-length password on my UNIX account
jfehlig@talkeetna:~> passwd Changing password for jfehlig. (current) UNIX password: New password: <enter> BAD PASSWORD: it is WAY too short passwd: password unchanged jfehlig@talkeetna:~> To start rejecting it now would be a non-backwards compatible change in our behaviour, so we can't really do that.
Ah, right. I think that was mentioned in one of the threads discussing the patch. Regards, Jim
participants (2)
-
Daniel P. Berrange -
Jim Fehlig