Re: -enablefips

[Markus Armbruster]

Gerd Hoffmann <kraxel@redhat.com> writes:

> On Tue, Jun 23, 2020 at 11:51:09PM -0400, John Snow wrote:
>> I never knew what this option did, but the answer is ... strange!
>> 
>> It's only defined for linux, in os-posix.c. When called, it calls
>> fips_set_state(true), located in osdep.c.
>> 
>> This will read /proc/sys/crypto/fips_enabled and set the static global
>> 'fips_enabled' to true if this setting is on.
>
> IIRC the idea is to have a global switch to enable fips compilance for
> the whole distro.  RH specific.  rhel-7 kernel has it.  rhel-8 kernel
> too, so it probably isn't obsolete.  Not present in mainline kernels.
>
> I'm wondering what the point of the -enablefips switch is.  Shouldn't
> qemu check /proc/sys/crypto/fips_enabled unconditionally instead?

The switch feels rather silly to me.  If you take the trouble to put
your host in FIPS mode, requiring -enable-fips to make QEMU to actually
honor it makes no sense.  If you don't, QEMU's -enable-fips has no
effect.

I may well misremember things (it's been years), but I vaguely recall
-enable-fips being a lame compromise between "this ought to be upstream"
and "FIPS is stupid, and I want nothing of it".

>> (Tangent: what does *this* setting actually control? Should QEMU
>> meaningfully change its behavior when it's set?)
>
> fips is a security policy ...
>
>> This static global is exposed via the getter fips_get_state(). This
>> function is called only by vnc.c, and appears to disable the use of the
>> password option for -vnc.
>
> ... yes, "no passwords" is one of the rules.  There are probably more.
>
>> (If we really do want to keep it, it should probably go under -global
>> somewhere instead to help reduce flag clutter, but we'd need to have a
>> chat about what fips compliance means for literally every other spot in
>> QEMU that is capable of using or receiving a cleartext password.)
>
> Yep.  IIRC for spice this is handled in libspice-server.  We need to
> look at blockdev encryption I guess.  Any other places where qemu uses
> passwords directly?  I think we don't have to worry about indirect usage
> (sasl).

I'd expect the SASL libraries to honor FIPS mode by themselves.  But
best ask someone who actually knows how FIPS mode is supposed to work.