Bug 1444426

Yaniv - can you take a look?

Hi Lucie, do you know when libvirt 3.2 will be available upstream? In fedora 25 latest build they have libvirt-2.2.0 , I see recent 3.2 build in [1]  but any idea when it will be upstream or in rhel7.3 by default?

[1] https://brewweb.engineering.redhat.com/brew/packageinfo?packageID=1989

If we will require that change in 4.1 I'll duplicate the bug, setting this one for 4.2 for now.

I asked Michal Privoznik and libvirt 3.2 will be in RHEL 7.4 as default, not in 7.3. And it is already in Fedora 26, 27 and in Fedora 27 should be libvirt 3.3 in few weeks.

*** Bug 1448354 has been marked as a duplicate of this bug. ***

I think we need to do following things:

- VDSM depends on cyrus-sasl-md5
- change the /etc/sasl2/libvirt.conf back to 

mech_list: digest-md5
sasldb_path: /etc/libvirt/passwd.db

Works as workaround for me.

(In reply to Martin Polednik from comment #5)
> I think we need to do following things:
> 
> - VDSM depends on cyrus-sasl-md5
> - change the /etc/sasl2/libvirt.conf back to 
> 
> mech_list: digest-md5
> sasldb_path: /etc/libvirt/passwd.db

No, you really should not configure digest-md5. It was disabled because it is a broken auth mechanism from a security POV. You want to set 'mech_list: scram-sha-1', as per the comments in the libvirt.conf file.

It should be backwards compatible with the existing passwd.db format used by the old digest-md5 method.

(In reply to Daniel Berrange from comment #8)
> (In reply to Martin Polednik from comment #5)
> > I think we need to do following things:
> > 
> > - VDSM depends on cyrus-sasl-md5
> > - change the /etc/sasl2/libvirt.conf back to 
> > 
> > mech_list: digest-md5
> > sasldb_path: /etc/libvirt/passwd.db
> 
> No, you really should not configure digest-md5. It was disabled because it
> is a broken auth mechanism from a security POV. You want to set 'mech_list:
> scram-sha-1', as per the comments in the libvirt.conf file.
> 
> It should be backwards compatible with the existing passwd.db format used by
> the old digest-md5 method.

The username/password is in our public repository. It's more of an anti-tamper than security thing.

(In reply to Martin Polednik from comment #9)
> (In reply to Daniel Berrange from comment #8)
> > (In reply to Martin Polednik from comment #5)
> > > I think we need to do following things:
> > > 
> > > - VDSM depends on cyrus-sasl-md5
> > > - change the /etc/sasl2/libvirt.conf back to 
> > > 
> > > mech_list: digest-md5
> > > sasldb_path: /etc/libvirt/passwd.db
> > 
> > No, you really should not configure digest-md5. It was disabled because it
> > is a broken auth mechanism from a security POV. You want to set 'mech_list:
> > scram-sha-1', as per the comments in the libvirt.conf file.
> > 
> > It should be backwards compatible with the existing passwd.db format used by
> > the old digest-md5 method.
> 
> The username/password is in our public repository. It's more of an
> anti-tamper than security thing.

That's still not a good reason to use 'digest-md5' when 'scram-sha-1' exists and doesn't suffer from broken design.

(In reply to Daniel Berrange from comment #10)
> (In reply to Martin Polednik from comment #9)
> > (In reply to Daniel Berrange from comment #8)
> > > (In reply to Martin Polednik from comment #5)
> > > > I think we need to do following things:
> > > > 
> > > > - VDSM depends on cyrus-sasl-md5
> > > > - change the /etc/sasl2/libvirt.conf back to 
> > > > 
> > > > mech_list: digest-md5
> > > > sasldb_path: /etc/libvirt/passwd.db
> > > 
> > > No, you really should not configure digest-md5. It was disabled because it
> > > is a broken auth mechanism from a security POV. You want to set 'mech_list:
> > > scram-sha-1', as per the comments in the libvirt.conf file.
> > > 
> > > It should be backwards compatible with the existing passwd.db format used by
> > > the old digest-md5 method.
> > 
> > The username/password is in our public repository. It's more of an
> > anti-tamper than security thing.
> 
> That's still not a good reason to use 'digest-md5' when 'scram-sha-1' exists
> and doesn't suffer from broken design.

I guess it can't hurt.

Related: why doesn't libvirt us scram plain as default? After upgrading my machines, I have to change even basic libvirt to use virsh. That would also not break oVirt on upgrade.

(In reply to Martin Polednik from comment #11)
> Related: why doesn't libvirt us scram plain as default? After upgrading my
> machines, I have to change even basic libvirt to use virsh. That would also
> not break oVirt on upgrade.

The libvirt default setup is designed for securing the TCP socket, where you need a mechanism that can provide encryption & authentication. GSSAPI/Kerberos is the only mechanism that can provide that. The SCRAM mechanism requires a separate encryption layer, so isn't suitable as a default.

Personally I'd just recommend deleting this oVirt use of SASL for the UNIX socket, and reverting to the libvirt default of polkit, as is used with OpenStack. It adds no security since the password is well known, and if you have a user with root  access who is reckless, virsh access is the least of your worries.

(In reply to Daniel Berrange from comment #12)
> Personally I'd just recommend deleting this oVirt use of SASL for the UNIX
> socket, and reverting to the libvirt default of polkit, as is used with
> OpenStack. It adds no security since the password is well known, and if you
> have a user with root  access who is reckless, virsh access is the least of
> your worries.

It works extremely well for "if you have to ask about password, don't touch it" scenario. But that should be doable with a polkit rule too I guess.

*** Bug 1446475 has been marked as a duplicate of this bug. ***

(In reply to Michal Skrivanek from comment #14)
> if scram-sha-1 can handle the existing user db it's the least risky change,
> we can push vdsm update to RHEL-7-RHEV-4 and RHEL-7-RHEV to cover all
> affected versons

FYI here's the demo scenario to show compatibility of existing DB

# grep ^mech_list /etc/sasl2/libvirt.conf
mech_list: digest-md5

# saslpasswd2 -a libvirt demo
Password: 
Again (for verification): 

# virsh hostname
Please enter your authentication name: demo
Please enter your password: 
t460

# vi /etc/sasl2/libvirtd.conf
...change to scram-sha-1...

# grep ^mech_list /etc/sasl2/libvirt.conf
mech_list: scram-sha-1

# systemctl restart libvirtd

# virsh hostname
Please enter your authentication name: demo
Please enter your password: 
t460

Hi Daniel,
when I try to apply mech_list: scram-sha-1 instead of digest-md5 - I get failed to connect to the hypervisor.

[root@dhcp-0-135 vdsm]# grep ^mech_list /etc/sasl2/libvirt.conf
mech_list: scram-sha-1
[root@dhcp-0-135 vdsm]# saslpasswd2 -a libvirt demo
Password: 
Again (for verification): 
[root@dhcp-0-135 vdsm]# virsh hostname
error: failed to connect to the hypervisor
error: authentication failed: authentication failed

libvirtd is running, and vdsm can't communicate with it. command line doesn't request for authentication as with digest-md5

[root@dhcp-0-135 vdsm]# virsh list
error: failed to connect to the hypervisor
error: authentication failed: authentication failed

[root@dhcp-0-135 vdsm]# virsh hostname
error: failed to connect to the hypervisor
error: authentication failed: authentication failed


Another question - don't you prefer, for safety, to Conflict this version of libvirt with those broken versions of vdsm?

(In reply to Yaniv Bronhaim from comment #17)
> Hi Daniel,
> when I try to apply mech_list: scram-sha-1 instead of digest-md5 - I get
> failed to connect to the hypervisor.
> 
> [root@dhcp-0-135 vdsm]# grep ^mech_list /etc/sasl2/libvirt.conf
> mech_list: scram-sha-1
> [root@dhcp-0-135 vdsm]# saslpasswd2 -a libvirt demo
> Password: 
> Again (for verification): 
> [root@dhcp-0-135 vdsm]# virsh hostname
> error: failed to connect to the hypervisor
> error: authentication failed: authentication failed
> 
> libvirtd is running, and vdsm can't communicate with it. command line
> doesn't request for authentication as with digest-md5

Presumably you are missing the cyrus-sasl-scram RPM.

verification notes: upgraded to fresh build of libvirt-3.2.0-5.el7 from libvirt-2.0.0-10.el7 (latest in centos7) while vdsm latest master is installed and running without my patch:

- upgrade only libvirt while vdsm was running - vdsm will be down after the upgrade and require an upgrade.

- upgrade only vdsm - still work as usual with older libvirt version

- upgrade vdsm and then libvirt  - vdsm will go down and require vdsm-tool configure call manually.

- upgrade both at the same time while vdsm is running (the only thing that should work fine) - tested over centos7.

any suggestion for more flows ?

I miss fresh installation of newest vdsm with libvirt 3.2 and maybe upgrade from engine. Otherwise it looks alright for me.

I wonder - we require now cyrus-sasl-scram - do we want to limit it only to 7.4 and above? does libvirt plan to backport 3.2 to rhel7.3?

I don't think I understand your question, Yaniv. Once el-7.4 is out, ovirt-4.1 does not need to continue support of 7.3.z. Your patch can safely require a package that is only available in 7.4 (it only means that your patch cannot be merged upstream before the package is available).

(In reply to Yaniv Bronhaim from comment #24)
> I wonder - we require now cyrus-sasl-scram - do we want to limit it only to
> 7.4 and above? does libvirt plan to backport 3.2 to rhel7.3?

Libvirt has no intention to make sure changes in pre-existing 7.x branches. IIUC, the VDSM patch for this makes VDSM totally independent of libvirt's default config, because it drops in a replacement SASL config file, completely ignoring whatever content libvirt had before. So it shouldn't matter what libvirt does to SASL configs at this point.

INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Tag 'v4.19.17' doesn't contain patch 'https://gerrit.ovirt.org/77534']
gitweb: https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=shortlog;h=refs/tags/v4.19.17

For more info please contact: infra

Vdsm changed sasl2 settings from gssapi to scram-sha-1
and started successfully (both: manual and from engine).

verified in vdsm-4.19.19-1.el7ev.x86_64, ovirt-engine-4.1.3.4-0.1.el7.noarch