-enablefips

-enablefips

[John Snow]

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.

(Tangent: what does *this* setting actually control? Should QEMU
meaningfully change its behavior when it's set?)

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.

This seems very high-level and abstract for something that ultimately
only disables VNC password authentication. Is this misleadingly abstract?

The docs state:
"enable FIPS 140-2 compliance"

Like hell it does.

Can we deprecate this? It was added in 2012 and never seemed to pursue
the mission laid out in the help file. If we do still want it, the
documentation should be changed dramatically to reflect what it actually
does.

This is so at risk of bit-rot, and a misleading crypto flag is certainly
worse than no crypto flag. I think it should just go.

(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.)

--js

Re: -enablefips

[Gerd Hoffmann]

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?

> (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).

take care,
  Gerd

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.

Re: -enablefips

[Daniel P. Berrangé]

On Wed, Jun 24, 2020 at 08:49:54AM +0200, Gerd Hoffmann wrote:
> 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?

Yes, but IIRC, there was a bit of a philisophical debate about the
value of FIPS and whether QEMU was going to accept it at all upstream.
I think the -enablefips switch was a compromise to get something
upstream.

> > (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.

It isn't so much "no passwords", rather in the VNC case the rule
we fal on is "no single DES" encryption algorithm !

Back when we added FIPS in QEMU, VNC was using the built-in DES
impl, and hence we needed to block this explicitly ourselves.

These days a sensible QEMU build will link to a crypto library
and get DES from there.  This crypto library will in turn block
our use of single DES when in FIPS mode, so QEMU won't have to
worry about it.

> > (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 don't think it is about passwords. Encryption algorithms were the
really key thing AFAIK, and the intent is that by using a common crypto
library you get the FIPS support for free.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: -enablefips

[Daniel P. Berrangé]

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.
> 
> (Tangent: what does *this* setting actually control? Should QEMU
> meaningfully change its behavior when it's set?)
> 
> 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.
> 
> This seems very high-level and abstract for something that ultimately
> only disables VNC password authentication. Is this misleadingly abstract?
> 
> The docs state:
> "enable FIPS 140-2 compliance"
> 
> Like hell it does.

It prevents the use of non-FIPS crypto in QEMU, so it isn't that
inaccurate.

> Can we deprecate this? It was added in 2012 and never seemed to pursue
> the mission laid out in the help file. If we do still want it, the
> documentation should be changed dramatically to reflect what it actually
> does.
> 
> This is so at risk of bit-rot, and a misleading crypto flag is certainly
> worse than no crypto flag. I think it should just go.

I think it can go.

FIPS support in QEMU is only needed if using our own crypto code which
lacks FIPS compliance, which essentially means our Single DES impl.

Anyone who cares about FIPS should be building QEMU with crypto provided
by libgcrypt. This will take care of FIPS compliance automatically,
so there's nothing QEMU needs do itself.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: -enablefips

[John Snow]

On 6/24/20 2:49 AM, Gerd Hoffmann wrote:
> 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?

It sounds like we want a compile-time flag that makes it mandatory
instead of optional where it doesn't do a good job of "enforcing" fips
mode. (If you accidentally, uh, omit it.)

Then the flag can go away. Compile the feature in or out. Toggle the
behavior using the /proc/sys/ flag.

Or, as Dan said, just get rid of it. It sounds like it's already handled
by our client libraries in 2020.

--js