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

[Alexander Graf]

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