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

[Anthony Liguori]

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