qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] vnc: disable VNC password authentication (se


From: Paul Moore
Subject: Re: [Qemu-devel] [PATCH v2] vnc: disable VNC password authentication (security type 2) when in FIPS mode
Date: Thu, 03 May 2012 16:58:52 -0400
User-agent: KMail/4.8.2 (Linux/3.3.4-gentoo; KDE/4.8.2; x86_64; ; )

On Thursday, May 03, 2012 11:11:16 AM Alexander Graf wrote:
> On 03.05.2012, at 11:09, Daniel P. Berrange wrote:
> > On Thu, May 03, 2012 at 11:06:18AM +0200, Alexander Graf wrote:
> >> On 03.05.2012, at 11:03, Daniel P. Berrange wrote:
> >>> On Thu, May 03, 2012 at 11:01:29AM +0200, Alexander Graf wrote:
> >>>> On 03.05.2012, at 10:57, Daniel P. Berrange wrote:
> >>>>> On Thu, May 03, 2012 at 10:51:15AM +0200, Alexander Graf wrote:
> >>>>>> On 03.05.2012, at 10:29, Daniel P. Berrange wrote:
> >>>>>>> On Wed, May 02, 2012 at 03:32:56PM -0400, Paul Moore wrote:
> >>>>>>>> FIPS 140-2 requires disabling certain ciphers, including DES, which
> >>>>>>>> is used
> >>>>>>>> by VNC to obscure passwords when they are sent over the network. 
> >>>>>>>> The
> >>>>>>>> solution for FIPS users is to disable the use of VNC password auth
> >>>>>>>> when the
> >>>>>>>> host system is operating in FIPS mode.
> >>>>>> 
> >>>>>> So that means "no password" is more secure according to FIPS than
> >>>>>> "DES encrypted password"?
> >>>>> 
> >>>>> No, FIPS is not making statements about the choice of auth methods.
> >>>>> FIPS is concerned with what encryption algorithms an application uses.
> >>>>> The requirements about whether authentication is required & what sort,
> >>>>> is upto other specifications (eg Common Criteria) to decide.
> >>>> 
> >>>> Hrm, so short-term this fixes things. But long-term, I think the
> >>>> better solution would be to implement the tight security model and
> >>> 
> >>>> use a real cipher:
> >>> That is certainly possible, but shouldn't have any bearing on whether
> >>> this patch is accepted. Note that QEMU already implements VeNCrypt
> >>> and SASL extensions both of which provide strong security
> >> 
> >> Hmm. Isn't the syslog message misleading then? Also, why would the
> >> whole password parameter be blocked then?
> > 
> > The password parameter is irrelevant for VeNCrypt & SASL authentication
> > types. They are configured via other parameters.
> 
> Ah, an error message hinting to the alternatives would be nice then :).

Fair enough.  I'll make the stderr notice suggest both VeNCrypt and SASL.

-- 
paul moore
security and virtualization @ redhat




reply via email to

[Prev in Thread] Current Thread [Next in Thread]