Bug 1480462

Summary: SASL auth stop working after upgrde to rhel7.4
Product: Red Hat Enterprise Linux 7 Reporter: Robin Hack <rhack>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED NOTABUG QA Contact: Lili Zhu <lizhu>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.4CC: berrange, dyuan, pkrempa, rbalakri, xuzhang, zpeng
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-22 11:28:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Robin Hack 2017-08-11 07:53:50 UTC
Description of problem:
Hello. I had libvirt configured with sasl auth via digest-md5. I understand that this can be unsecure however after upgrade, the file /etc/sasl2/libvirt.conf has been rewritten to default version, without any warning, which supports kerberos. I don't have kerberos infrastructure so, after reboot, I was unable to schedule machines from beaker because libvirt weren't able to do sasl via digest-md5.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. configure libvirt with sasl via digest-md5
2. upgrade to rhel7.4
3.

Actual results:
/etc/sasl2/libvirt.conf is rewritten to krb5 auth

Expected results:
Leave configuration as is?

Additional info:
When I used yum whatprovides /etc/sasl2/libvirt.conf
Then file is provided by two packages.
libvirt-libs-3.2.0-14.el7_4.2.x86_64
libvirt-client-2.0.0-10.el7_3.9.x86_64

However I have only libvirt-client package installed on my system.

Comment 2 Robin Hack 2017-08-11 08:00:27 UTC
Update:

On rhel 7.3 I have installed:
[root@smicro-s1028r-02 ~]# rpm -qa libvirt\*
libvirt-client-2.0.0-10.el7_3.9.x86_64
libvirt-daemon-driver-network-2.0.0-10.el7_3.9.x86_64
libvirt-daemon-config-nwfilter-2.0.0-10.el7_3.9.x86_64
libvirt-daemon-driver-secret-2.0.0-10.el7_3.9.x86_64
libvirt-2.0.0-10.el7_3.9.x86_64
libvirt-daemon-2.0.0-10.el7_3.9.x86_64
libvirt-daemon-driver-storage-2.0.0-10.el7_3.9.x86_64
libvirt-daemon-driver-qemu-2.0.0-10.el7_3.9.x86_64
libvirt-daemon-driver-lxc-2.0.0-10.el7_3.9.x86_64
libvirt-daemon-driver-interface-2.0.0-10.el7_3.9.x86_64
libvirt-daemon-driver-nwfilter-2.0.0-10.el7_3.9.x86_64
libvirt-daemon-config-network-2.0.0-10.el7_3.9.x86_64
libvirt-daemon-driver-nodedev-2.0.0-10.el7_3.9.x86_64

On rhel 7.4 I have installed:
[root@smicro-s1028r-01 ~]# rpm -qa libvirt\*
libvirt-daemon-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-interface-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-storage-mpath-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-config-network-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-storage-scsi-3.2.0-14.el7_4.2.x86_64
libvirt-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-nwfilter-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-secret-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-storage-core-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-storage-rbd-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-storage-iscsi-3.2.0-14.el7_4.2.x86_64
libvirt-libs-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-config-nwfilter-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-nodedev-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-storage-logical-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-storage-disk-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-storage-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-lxc-3.2.0-14.el7_4.2.x86_64
libvirt-client-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-storage-gluster-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-network-3.2.0-14.el7_4.2.x86_64
libvirt-daemon-driver-qemu-3.2.0-14.el7_4.2.x86_64


On rhel7.4 I have both packages:
libvirt-libs and libvirt-client installed.
According to yum whatprovides, both packages contains /etc/sasl2/libvirt.conf

Comment 3 Daniel Berrangé 2017-08-11 08:37:14 UTC
(In reply to Robin Hack from comment #0)
> Description of problem:
> Hello. I had libvirt configured with sasl auth via digest-md5. I understand
> that this can be unsecure however after upgrade, the file
> /etc/sasl2/libvirt.conf has been rewritten to default version, without any
> warning, which supports kerberos. I don't have kerberos infrastructure so,
> after reboot, I was unable to schedule machines from beaker because libvirt
> weren't able to do sasl via digest-md5.

[snip]

> Steps to Reproduce:
> 1. configure libvirt with sasl via digest-md5
> 2. upgrade to rhel7.4
> 3.
> 
> Actual results:
> /etc/sasl2/libvirt.conf is rewritten to krb5 auth
> 
> Expected results:
> Leave configuration as is?

Digest-md5 was removed as the default configuration because of its unacceptably insecure design. Kerberos is the only SASL mechanism that offers both authentication & encryption, that has a credible security level suitable for protecting the libvirtd TCP socket.  If using TLS or UNIX sockets, however, you could optionally use  scram-sha1 mechanism instead which provides authentication only. This can be achieved by edtting the /etc/sasl2/libvirt.conf file.

Comment 4 Robin Hack 2017-08-11 09:13:09 UTC
> Digest-md5 was removed as the default configuration because of its
> unacceptably insecure design. Kerberos is the only SASL mechanism that
> offers both authentication & encryption, that has a credible security level
> suitable for protecting the libvirtd TCP socket.  If using TLS or UNIX
> sockets, however, you could optionally use  scram-sha1 mechanism instead
> which provides authentication only. This can be achieved by edtting the
> /etc/sasl2/libvirt.conf file.

Hello. I understand security concerns and I found note in configuration file about that. But after upgrade I ended up with non-working system without any warning :(. I think that just revert configuration to default because is insecure without any warning is something not nice on production systems.

Comment 16 Peter Krempa 2017-08-22 11:28:01 UTC
Since the change was deliberate and we should not use the insecure method we will not change this back.