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 <pmo...@redhat.com> 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 <pmo...@redhat.com> > > > > > > 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
