On Thursday, June 07, 2012 09:21:12 AM Paul Moore wrote: > On Thursday, June 07, 2012 12:31:25 PM Alexander Graf wrote: > > On 07.06.2012, at 05:10, Anthony Liguori wrote: > > > On 06/07/2012 06:56 AM, Paul Moore wrote: > > >> On Wednesday, June 06, 2012 01:56:52 AM Alexander Graf wrote: > > >>> The other one (FIPS) is basically a list of encryption algorithms that > > >>> are deemed OK and not crackable within seconds by anyone. > > >>> > > >>> Only one of the 2 doesn't help much. In combination they actually > > >>> enhance security. This patch is only about FIPS though. > > >> > > >> I don't have much to add beyond what Alex already posted. FIPS 140-2 > > >> outlines a set of security requirements for systems implementing > > >> cryptography in a variety of forms; the full requirements are likely > > >> beyond the scope here but you can always read the full specification > > >> (Google knows where to find the document). > > >> > > >> The relevant portion appears to be annex A which lists the approved > > >> ciphers and their approved uses; DES is not listed as an approved > > >> cipher > > >> and that is the main problem we are trying to solve right now. > > > > > > But does FIPS mandate that it's impossible for a user to use an > > > unapproved > > > cipher? > > > > > > IOW, is just having this feature implemented at the libvirt level good > > > enough to satisfy FIPS? Do we really need to do this in QEMU? > > > > What would implementing it in libvirt buy us? That only stacks using > > libvirt can be FIPS certified? That any time a management stack that does > > not use libvirt they need to duplicate that code to be FIPS certified? > > Once again, I think Alex summed it up nicely. > > While most users probably use QEMU via libvirt, the fact remains that you > can always run QEMU directly so simply disallowing VNC's password > authentication doesn't really solve the FIPS problem.
I haven't seen any more discussion about this so I'm going to go ahead and post a v4 patch with the syslog bits removed. -- paul moore security and virtualization @ redhat
