Re: [Qemu-devel] [PATCH v4] vnc: disable VNC password authentication (security type 2) when in FIPS mode

[Paul Moore]

On Tuesday, July 31, 2012 09:12:57 PM Daniel P. Berrange wrote:
> On Tue, Jul 31, 2012 at 02:52:07PM -0500, Anthony Liguori wrote:
> > Paul Moore <address@hidden> writes:
> > > On Friday, June 08, 2012 05:38:12 PM 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.
> > >> 
> > >> This patch causes QEMU to emit a message to stderr when the host system
> > >> is
> > >> running in FIPS mode and a VNC password was specified on the commend
> > >> line.
> > >> If the system is not running in FIPS mode, or is running in FIPS mode
> > >> but
> > >> VNC password authentication was not requested, QEMU operates normally.
> > >> 
> > >> Signed-off-by: Paul Moore <address@hidden>
> > > 
> > > Hi Anthony,
> > > 
> > > Any word on this patch?  Other than Daniel Berrange's reviewed-by tag,
> > > the
> > > discussion of the v4 patch has been quiet and I think we addressed all
> > > the
> > > other remaining issues in the discussion attached to the v2 patch
> > > posting.
> > 
> > I asked for the specific language in FIPS mandating this.  I don't see
> > any other VNC server implementing a check like this.  I would rather do
> > this in a more user friendly fashion like make it a config file option
> > that a user can set while in fips mode.
> 
> The FIPS standard doesn't refer to particular applications like VNC.
> As Paul says earlier, FIP 140-2 requires that DES (and certain other
> ciphers) not be used in any applications which are running in a FIPS
> compliant environment. Since VNC auth uses DES, this auth scheme
> cannot be permitted in a FIPS environment.
> 
> The reason no other VNC server does this is almost certainly because
> none of their developers have ever tried to have their code work in
> a FIPS environment, so I don't think that's a relevant comparison.
> 
> I'm not really sure what addding more configuration options gains
> us here. The choice of auth mode is already configurable. This patch
> is about ensuring that the user is not allowed to configure it, if
> FIPS mode is in effect (as indicated by the kernels syfs tunable).
> So in fact adding config params doesn't really address this.
> 
> The proposed patch is already very straightforward, is using the
> official interface exposed by the upstream kernel to userspace &
> has negligable maintenence burden IMHO.

I've got nothing to add other than to say that I agree 100% with Daniel's 
comments above.

-- 
paul moore
security and virtualization @ redhat