* Re: -enablefips
2020-06-24 6:49 ` -enablefips Gerd Hoffmann
@ 2020-06-24 8:34 ` Markus Armbruster
2020-06-24 8:58 ` -enablefips Daniel P. Berrangé
2020-06-24 15:09 ` -enablefips John Snow
2 siblings, 0 replies; 6+ messages in thread
From: Markus Armbruster @ 2020-06-24 8:34 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: Daniel P. Berrange, John Snow, qemu-devel
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: -enablefips
2020-06-24 6:49 ` -enablefips Gerd Hoffmann
2020-06-24 8:34 ` -enablefips Markus Armbruster
@ 2020-06-24 8:58 ` Daniel P. Berrangé
2020-06-24 15:09 ` -enablefips John Snow
2 siblings, 0 replies; 6+ messages in thread
From: Daniel P. Berrangé @ 2020-06-24 8:58 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: John Snow, qemu-devel, Markus Armbruster
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 :|
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: -enablefips
2020-06-24 6:49 ` -enablefips Gerd Hoffmann
2020-06-24 8:34 ` -enablefips Markus Armbruster
2020-06-24 8:58 ` -enablefips Daniel P. Berrangé
@ 2020-06-24 15:09 ` John Snow
2 siblings, 0 replies; 6+ messages in thread
From: John Snow @ 2020-06-24 15:09 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: Daniel P. Berrange, qemu-devel, Markus Armbruster
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
^ permalink raw reply [flat|nested] 6+ messages in thread