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.

On Mon, Aug 01, 2016 at 10:00:05AM -0600, Jim Fehlig wrote: > On 08/01/2016 03:13 AM, Daniel P. Berrange wrote: >> 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. > 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.