[libvirt] Question about LSN-2016-0001

[Jim Fehlig]

On 08/01/2016 10:14 AM, Daniel P. Berrange wrote:
> 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.

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 at talkeetna:~> passwd
>> Changing password for jfehlig.
>> (current) UNIX password:
>> New password: <enter>
>> BAD PASSWORD: it is WAY too short
>> passwd: password unchanged
>> jfehlig at 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