On 05.06.2012, at 03:23, Anthony Liguori wrote: > On 06/05/2012 09:08 AM, Alexander Graf wrote: >> >> On 05.06.2012, at 03:03, Anthony Liguori wrote: >> >>> On 06/05/2012 08:55 AM, Alexander Graf wrote: >>>> >>>> On 05.06.2012, at 01:54, Anthony Liguori wrote: >>>> >>>>> Have you ever experienced a random failure on an SELinux box that made no >>>>> logical sense? Out of desperation, you setenforce 0 and magically, >>>>> thinks work again. >>>> >>>> Yeah - I never understood how anyone thought it makes sense to enable >>>> SELinux globally be default.... Either way, FIPS hopefully isn't something >>>> you find enabled by accident anywhere. >>>> >>>>> Even if the user enabled fips mode, they may not understand that this >>>>> means VNC authentication will stop working. Providing an option (1) >>>>> allows the user to discover what the problem is (2) makes the behavior >>>>> much more clear. >>>> >>>> Where would you want the option to live? Compile time would be useless - >>>> users don't recompile QEMU, they take binary packages. A runtime option? >>>> Who would enable that runtime option then? Libvirt by default I suppose? >>>> So you're back in the same hell. RH would patch libvirt to always pass in >>>> -enable-fips and nothing would be different. >>> >>> A QemuOpts option that is disabled by default but can be enabled through >>> /etc/qemu/target-x86_64.conf >>> >>> If any distribution wants to enable it as part of the default >>> configuration, they certainly can. But a user can override it if they want >>> to. >>> >>> Likewise, libvirt can enable it by default if they are so inclined. At >>> least the qemu logs from libvirt will show -enable-fips-mode >>> >>>> >>>>> Removing features based on a magic procfs variable with no input from the >>>>> user is a bad idea IMHO. >>>> >>>> But it's the design of the Linux FIPS model. >>> >>> Just because someone made a bad choice, that doesn't mean we have to >>> continue to make bad choices ourselves. >>> >>> This whole feature is ridiculous from a technical perspective. As you >>> said, disabling VNC auth but allowing no-password to be used is simply >>> moronic. >>> >>> I understand why we have to support these things, but it should not be the >>> default behavior. >> >> Fair enough, but I don't think a >> >> ### log file ### >> >> qemu-kvm<a lot of options> -enable-fips<a lot of other options> >> >> ### end of log file ### >> >> vs >> >> ### log file ### >> >> qemu-kvm<even more options> <option that sets vnc password> >> WARNING: your VNC password has just been deactivated >> >> ### end of log file ### >> >> make too much of a difference. >> >> Which gets me to a new idea. Why not exit(1) when we detect FIPS and a >> password is set? I agree with the assessment that we should never silently >> drop features. So the best way to make sure that the user knows he did >> something stupid (enable FIPS, but require a non-FIPS compliant >> authentication method) would be to just quit, no? > > I think my primary requirement is: allow a user to use vnc authentication > even when fips mode is active by using some command line option.
That's where we disagree. To me, fips mode enabled in /proc/somewhere is as good as passing in -enable-fips on the command line. So it's almost the same as -enable-kvm. I don't want -enable-kvm to silently not use KVM, I want QEMU to bail out because I've asked it to do something it can't do. If I pass -enable-fips -vnc-passwd foo, I want to have QEMU bail out. Since /proc/foo/fips_mode==1 is equivalent to -enable-fips, I want the same effect there. But then again, most people in this world won't care, because they won't enable FIPS either way ;). So we've probably already wasted more time discussing this than any user would have trying to debug why his password authentication wouldn't work. Alex
