Bug 817067

Just reading this - when running in secure FIPS-140 mode, we should make qemu/VNC less secure?

It is well established that VNC's password based authentication has a number of security faults; think of this change not as making qemu/VNC less secure, but rather as limiting/removing functionality which could lend a false sense of security to users.

It should also be noted that this doesn't affect the default qemu/libvirt/vnc behavior.  If started via libvirt, qemu's VNC server binds itself to localhost and doesn't use password authentication; it requires users to login to the host system before they can acces the VNC server.

Paul, I think Bill is expressing the same concern that I mentioned on the original bz. Right now, if you select a DES based authentication, the application is aborted. It fails safely. My understanding of the fix is that it will now fail open. Meaning that instead of securely denying access, it now allows any access. My thoughts were that it should print a meaningful error message and exit. Under no circumstance should it fail such that there is no protection when protection was intended.

bz 578629 also depends on this.

(In reply to comment #3)
> Paul, I think Bill is expressing the same concern that I mentioned on the
> original bz. Right now, if you select a DES based authentication, the
> application is aborted. It fails safely. My understanding of the fix is that it
> will now fail open. Meaning that instead of securely denying access, it now
> allows any access. My thoughts were that it should print a meaningful error
> message and exit. Under no circumstance should it fail such that there is no
> protection when protection was intended.

Steve, I believe your understanding is incorrect.  As explained in BZ 805676, comment 33:

 "... beyond disabling VNC password authentication and emitting a syslog
  message about operating in 'FIPS mode', QEMU will exit if configured to
  run as a password authenticated VNC server.  If QEMU is configured to run
  as an unauthenticated VNC server then it will continue to run as expected."

With the proposed patches qemu continues to fail safely, and not fail open.  Perhaps what is confusing you is that the proposed patches only cause qemu to fail when VNC password authentication is requested?  Or am I missing something?

Maybe what is confusing is that VNC is considered unauthenticated and yet requires a DES based password. As long as we fail closed when it must, we are OK.

(In reply to comment #6)
> Maybe what is confusing is that VNC is considered unauthenticated and yet
> requires a DES based password.

I don't understand this statement.

> As long as we fail closed when it must, we are OK.

The proposed patch causes qemu to fail when the user requests DES based password authentication and the system is operating in FIPS mode.  I believe this is the right thing to do, and should satisfy your requirements.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
We should add a note to the release notes indicating that VNC password authentication is disabled when the system is operating in "FIPS mode".

A fix for this has been accepted upstream; see commit 0f66998ff6d5d2133b9b08471a44e13b11119e50.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-We should add a note to the release notes indicating that VNC password authentication is disabled when the system is operating in "FIPS mode".+We should add a note to the release notes indicating that VNC password authentication is disabled when the system is operating in "FIPS mode" and the "-enable-fips" option is given to QEMU.

This fix was pulled in as part of the QEMU 1.5-stable releases.  It is present in qemu-kvm-1.5.3-6.el7 and possibly earlier releases as well.

Reproduce this bug with qemu-kvm-1.5.3-3.el7.x86_64.

host:
[root@localhost home]# rpm -qa |grep qemu
ipxe-roms-qemu-20130517-1.gitc4bce43.el7.noarch
qemu-img-1.5.3-3.el7.x86_64
qemu-kvm-common-1.5.3-3.el7.x86_64
qemu-kvm-1.5.3-3.el7.x86_64
qemu-kvm-tools-1.5.3-3.el7.x86_64
kernel-3.10.0-54.el7.x86_64

steps:
1 enable FIPS mode.
#yum install dracut-fips
#rpm -qa |grep dracut
dracut-network-033-40.el7.x86_64
dracut-033-40.el7.x86_64
dracut-fips-033-40.el7.x86_64
dracut-config-rescue-033-40.el7.x86_64

#setting configuring "PRELINKING=no" in the /etc/sysconfig/prelink configuration file

#prelink -u -a
#dracut -f

add "fips=1" and boot partition in kernel command line
linux16 /vmlinuz-3.10.0-54.el7.x86_64 root=/dev/mapper/rhel_intel--5205--32--1-root ro rd.lvm.lv=rhel_intel-5205-32-1/swap console=tty0 vconsole.keymap=us reboot=pci console=ttyS0,115200 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=rhel_intel-5205-32-1/root biosdevname=0 crashkernel=256M LANG=en_US.UTF-8 fips=1 boot=/dev/sda1

2  boot guest with:
/usr/libexec/qemu-kvm -hda storage.qcow2 -monitor stdio -vnc :0,password

Result:
qemu will boot up guest without warning.

But failed verify this bug with qemu-kvm-1.5.3-19.el7.x86_64.
After update qemu-kvm package, executed "/usr/libexec/qemu-kvm -hda storage.qcow2 -monitor stdio -vnc :0,password", qemu-kvm process boot up,
not found the warning.

Can you please confirm that the system was operating in FIPS mode by cat'ing the "fips_enabled" file in /proc?

 # cat /proc/sys/crypto/fips_enabled

[root@intel-5205-32-1 ~]# cat /proc/sys/crypto/fips_enabled 
1
[root@intel-5205-32-1 ~]# cd /home/
[root@intel-5205-32-1 home]# /usr/libexec/qemu-kvm -hda storage.qcow2 -monitor stdio -vnc :0,password
QEMU 1.5.3 monitor - type 'help' for more information
(qemu) q
[root@intel-5205-32-1 home]# rpm -qa |grep qemu
qemu-guest-agent-1.5.3-19.el7.x86_64
qemu-kvm-tools-1.5.3-19.el7.x86_64
ipxe-roms-qemu-20130517-1.gitc4bce43.el7.noarch
qemu-kvm-common-1.5.3-19.el7.x86_64
qemu-kvm-1.5.3-19.el7.x86_64
qemu-kvm-debuginfo-1.5.3-19.el7.x86_64
qemu-img-1.5.3-19.el7.x86_64

My apologies, I should have noticed this sooner; please add "-enable-fips" to the QEMU command line.

Thanks, Verify this bug with qemu-kvm-1.5.3-19.el7.x86_64

host:
qemu-kvm-1.5.3-19.el7.x86_64
kernel-3.10.0-54.el7.x86_64

Result:
# /usr/libexec/qemu-kvm -hda storage.qcow2 -monitor stdio -vnc :0,password --enable-fips
QEMU 1.5.3 monitor - type 'help' for more information
(qemu) qemu-kvm: Failed to start VNC server on `:0,password': VNC password auth disabled due to FIPS mode, consider using the VeNCrypt or SASL authentication methods as an alternative

1 This bug has been fixed.
2 Seems rhel6 not support "-enable-fips" flag, will you backport this flag to rhel6 ?

(In reply to mazhang from comment #21)
> Seems rhel6 not support "-enable-fips" flag, will you backport this flag
> to rhel6 ?

QEMU/FIPS support for RHEL6 was addressed in BZ #817066.

Hi Paul,

Sorry, make you misunderstanding, QEMU/FIPS support for RHEL6.
But I meant the flag "--enable-fips" in RHEL6.5 qemu-kvm command line.
As I tried, RHEL6.5 qemu-kvm did not support this flag, but RHEL7 did.
So support QEMU/FIPS without "--enable-fips" in RHEL6.5 command line was expected?

Btw, does this affect spice with password?

Thanks,
Mazhang.

(In reply to mazhang from comment #24)
> Hi Paul,
> 
> Sorry, make you misunderstanding, QEMU/FIPS support for RHEL6.
> But I meant the flag "--enable-fips" in RHEL6.5 qemu-kvm command line.
> As I tried, RHEL6.5 qemu-kvm did not support this flag, but RHEL7 did.
> So support QEMU/FIPS without "--enable-fips" in RHEL6.5 command line was
> expected?

No, the "-enable-fips" option is only needed with RHEL7; the FIPS logic is enabled by default in RHEL6.

Sorry for the confusion.

> Btw, does this affect spice with password?

No, the "-enable-fips" only affects the VNC password at this time.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.