[Qemu-devel] Re: [PATCH] vnc: Fix password expiration through 'change vnc ""'

[Anthony Liguori <aliguori@linux.vnet.ibm.com>]

On 02/14/2011 07:56 AM, Gerd Hoffmann wrote:
> On 02/14/11 13:10, Anthony Liguori wrote:
>> On 02/14/2011 04:57 AM, Gerd Hoffmann wrote:
>>> On 01/31/11 21:43, Anthony Liguori wrote:
>>>> commit 52c18be9e99dabe295321153fda7fce9f76647ac introduced a
>>>> regression in the
>>>> change vnc password command that changed the behavior of setting 
>>>> the VNC
>>>> password to an empty string from disabling login to disabling
>>>> authentication.
>>>>
>>>> This commit refactors the code to eliminate this overloaded 
>>>> semantics in
>>>> vnc_display_password and instead introduces the
>>>> vnc_display_disable_login. The
>>>> monitor implementation then determines the behavior of an empty or
>>>> missing
>>>> string.
>>>
>>> Hmm, now about simply never ever changing vs->auth?
>>
>> If auth is none and you do a vnc change password "" then if we don't set
>> vs->auth to vnc, it won't have the desired effect.
>
> If you want a password-protected vnc session you should better 
> explicitly say so using '-vnc :0,password', otherwise you'll have a 
> window (between qemu start and setting the password) where vnc clients 
> can connect without a password.
>
> Going from "none" to "vnc" automagically when setting a password 
> encourages this insecure way to enable password protection.  IMHO we 
> should stop doing this.  There are backward compatibility issues 
> though as qemu did this for quite some time ...

Yeah, change vnc is deprecated, set-password has sane semantics.

> Going from "vnc" to "none" automagically when setting a empty password 
> is a no-go from a security point of view, especially as older qemu 
> versions did *not* do that. ]

Yup, this was the reason for the CVE.

> I don't think we'll need a monitor command to switch authentication 
> methods on the fly.  YMMV.

Actually, I do, but that's far off on my radar screen.

One thing we're noticing is that QEMU is not terribly forgiving in a 
hosting environment.  If you make a mistake configuring something (like 
use the wrong auth type), you're only recourse is restarting the guest 
with the new options.  Restarting a guest of a paying customer == 
unhappy customer.

The more we can change without restarting a guest the better IMHO.

Regards,

Anthony Liguori

> cheers,
>   Gerd
>