** Description changed: + [Impact] + + * libvirt in Focal in some cases e.g. with non local users + needs to resolve those users. When trying to do so it fails + due to apparmor isolation and breaks badly. + + * In later and former releases this issue isn't triggered, + but it is unknown which (potentially complex) set of changes + did that. A simple apparmor rule would help to allow libvirt + to better function in environments with non known user IDs. + + [Test Plan] + + * Following these steps in an unfixed release triggers the issue + + sudo apt update; sudo apt dist-upgrade -y + sudo apt install -y sssd sssd-ldap slapd ldap-utils openssl expect lsb-release libvirt-clients libvirt-daemon-system ubuntu-dev-tools + pull-lp-source sssd + cd sssd-2.4.1 + echo "*;*;*;Al0000-2400;libvirt" | sudo tee -a /etc/security/group.conf + head -n -5 debian/tests/ldap-user-group-ldap-auth > debian/tests/lp1890858-test + chmod +x debian/tests/lp1890858-test + sudo ./debian/tests/lp1890858-test + sudo systemctl restart libvirtd + # ensure it works in a normal login + virsh list + journalctl -u libvirtd + # try the sssd login + sudo login + # use testuser1 / testuser1secret to log in + virsh list + + If affected this will not work reporting an error like: + $ virsh list + error: failed to connect to the hypervisor + error: End of file while reading data: Input/output error + + And in dmesg/journal an apparmor denial like: + + Jun 14 11:25:26 ldap.example.com audit[48330]: AVC apparmor="DENIED" + operation="bind" profile="libvirtd" pid=48330 comm="rpc-worker" + family="unix" sock_type="dgram" protocol=0 requested_mask="bind" + denied_mask="bind" addr="@userdb-f283d575d74df972f9e10bd14d0befe3" + + + [Where problems could occur] + + * Allowing a little bit more to a daemon that already is rather powerful + and open in regard to it's profile usually isn't changing behavior. + If anything it would be considered a potential risk, but this rule + should be ok to be added and ubuntu-security confirmed this. + + [Other Info] + + * Comment 38 confirms that this should be ok - from the security Teams + POV. https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1890858/comments/38 + + + + + --- + On some focal 20.04 systems, users are seeing "QEMU/KVM - Not Connected" when they attempt to use virt-manager to manage virtual machines. AppArmor denials like the following are seen in the logs: sudo grep libvirt /var/log/syslog | grep -i apparmor | grep -i denied Jun 28 14:53:27 koromicha kernel: [ 334.660844] audit: type=1400 audit(1593345207.778:951): apparmor="DENIED" operation="bind" profile="libvirtd" pid=12254 comm="libvirtd" family="unix" sock_type="dgram" protocol=0 requested_mask="bind" denied_mask="bind" addr="@userdb-6228daaaf66b14dfd14d93ef46d962c3" Jun 28 14:54:19 koromicha kernel: [ 386.034970] audit: type=1400 audit(1593345259.145:952): apparmor="DENIED" operation="bind" profile="libvirtd" pid=14311 comm="libvirtd" family="unix" sock_type="dgram" protocol=0 requested_mask="bind" denied_mask="bind" addr="@userdb-c861507740da1fa0c3356ad3b78bffe9" Jun 28 15:02:30 koromicha kernel: [ 877.339057] audit: type=1400 audit(1593345750.437:968): apparmor="DENIED" operation="bind" profile="libvirtd" pid=16175 comm="libvirtd" family="unix" sock_type="dgram" protocol=0 requested_mask="bind" denied_mask="bind" addr="@userdb-7d70643a9f8da0342f6359907817b664" Users have reported that the "solution" is to disable the AppArmor profile. More details, screenshots, etc. can be found here: https://kifarunix.com/how-to-fix-qemu-kvm-not-connected-error-on- ubuntu-20-04/
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1890858 Title: AppArmor profile causes QEMU/KVM - Not Connected To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1890858/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
