Potential privilege escalation with the default libvirtd TLS config

[Oliver Walsh]

With the default TLS setup, any service with a certificate from the CA will be granted access to libvirtd.

There are a number of options to address this:
- use a different CA just for libvirt access
- filter allowed clients
- enable SASL auth for libvirtd
- disabled libvirt TLS

[Steven Hardy (shardy)]

Triaged as this is already assigned, we should discuss the plan for merging/backporting before making this public,

[Emilien Macchi (emilienm)]

We should reach Summer Long <email address hidden> if whether or not embargo is required on this issue, and if a CVE is accurate.

[Emilien Macchi (emilienm)]

IMHO, we should use enable SASL auth for libvirtd and filter allowed clients at minimum.
Having an dedicated CA is good but I think not enough; I like the SASL layer for credentials, which will allow us to have granular authentification and enable PolicyKit for example.

[Oliver Walsh (owalsh)]

Do we have puppet support for managing SASL?

[Oliver Walsh (owalsh)]

BTW we had to drop polkit when we containerized this.

[Joshua Padman (jpadman)]

Thank you for the add and the info. Summer Long normally takes Director
etc but Summit!

Cheers,
Josh

On 07/11/17 12:30, Oliver Walsh wrote:
> BTW we had to drop polkit when we containerized this.
>

--
Joshua Padman / Red Hat Product Security

[Oliver Walsh (owalsh)]

Libvirt TLS has been disabled in https://review.openstack.org/#/q/I6a5e4db1b6dd6bc8b7e73e53b614b070d15b8a23

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/tripleo-heat-templates 8.0.0.0b2 development milestone.