[Touch-packages] [Bug 1890858] Re: AppArmor profile causes QEMU/KVM - Not Connected
The apparmor section of this is now properly covered in bug 1932537, therefore I'm dropping the apparmor task from this one. ** No longer affects: apparmor (Ubuntu) ** No longer affects: apparmor (Ubuntu Focal) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1890858 Title: AppArmor profile causes QEMU/KVM - Not Connected Status in libvirt package in Ubuntu: Invalid Status in libvirt source package in Focal: Fix Committed Bug description: [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 "*;*;*;Al-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/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1890858/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890858] Re: AppArmor profile causes QEMU/KVM - Not Connected
Thanks for the quick test, works for me as well. The global verification-done tag might be needed as well for the tools to work, adding that back. ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1890858 Title: AppArmor profile causes QEMU/KVM - Not Connected Status in apparmor package in Ubuntu: Invalid Status in libvirt package in Ubuntu: Invalid Status in apparmor source package in Focal: New Status in libvirt source package in Focal: Fix Committed Bug description: [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 "*;*;*;Al-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/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1890858/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890858] Re: AppArmor profile causes QEMU/KVM - Not Connected
** Tags removed: verification-needed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1890858 Title: AppArmor profile causes QEMU/KVM - Not Connected Status in apparmor package in Ubuntu: Invalid Status in libvirt package in Ubuntu: Invalid Status in apparmor source package in Focal: New Status in libvirt source package in Focal: Fix Committed Bug description: [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 "*;*;*;Al-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/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1890858/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890858] Re: AppArmor profile causes QEMU/KVM - Not Connected
I have successfully tested the libvirt/6.0.0-0ubuntu8.10 packages from focal-proposed as requested. The following packages where upgraded to 6.0.0-0ubuntu8.10: libvirt-clients libvirt-daemon libvirt-daemon-driver-qemu libvirt-daemon-driver-storage-rbd libvirt-daemon-system libvirt-daemon-system-systemd libvirt0 Afterwards I was able to connect to libvirtd with my domain user as expected. FYI: I have opened a separate bug report for cups, since the crashing issue is fixed by this as well: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1932537 Thanks to everyone involved for the quick resolution! ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1890858 Title: AppArmor profile causes QEMU/KVM - Not Connected Status in apparmor package in Ubuntu: Invalid Status in libvirt package in Ubuntu: Invalid Status in apparmor source package in Focal: New Status in libvirt source package in Focal: Fix Committed Bug description: [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 "*;*;*;Al-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/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1890858/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touc
[Touch-packages] [Bug 1890858] Re: AppArmor profile causes QEMU/KVM - Not Connected
Hello Mike, or anyone else affected, Accepted libvirt into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libvirt/6.0.0-0ubuntu8.10 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-focal. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: libvirt (Ubuntu Focal) Status: Triaged => Fix Committed ** Tags added: verification-needed verification-needed-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1890858 Title: AppArmor profile causes QEMU/KVM - Not Connected Status in apparmor package in Ubuntu: Invalid Status in libvirt package in Ubuntu: Invalid Status in apparmor source package in Focal: New Status in libvirt source package in Focal: Fix Committed Bug description: [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 "*;*;*;Al-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
[Touch-packages] [Bug 1890858] Re: AppArmor profile causes QEMU/KVM - Not Connected
FYI - Uploaded to Focal-unapproved -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1890858 Title: AppArmor profile causes QEMU/KVM - Not Connected Status in apparmor package in Ubuntu: Invalid Status in libvirt package in Ubuntu: Invalid Status in apparmor source package in Focal: New Status in libvirt source package in Focal: Triaged Bug description: [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 "*;*;*;Al-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/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1890858/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890858] Re: AppArmor profile causes QEMU/KVM - Not Connected
FYI MP https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/404124 updated with the more restricted rule. I also updated the PPA with the new rule. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1890858 Title: AppArmor profile causes QEMU/KVM - Not Connected Status in apparmor package in Ubuntu: Invalid Status in libvirt package in Ubuntu: Invalid Status in apparmor source package in Focal: New Status in libvirt source package in Focal: Triaged Bug description: [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 "*;*;*;Al-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/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1890858/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890858] Re: AppArmor profile causes QEMU/KVM - Not Connected
Thanks Seth and Robert, I'll follows Seth advise and for now propose (B) being the fix for libvirt. But I'll add a task for apparmor (which carries abstraction/namespace) as that still might be an avenue worthwhile to follow independent to this libvirt fix. If more people speak up or we find more cases affected then adding it there eventually seems good. ** Also affects: apparmor (Ubuntu) Importance: Undecided Status: New ** Changed in: apparmor (Ubuntu) Status: New => Invalid ** Changed in: libvirt (Ubuntu) Status: Fix Released => Invalid ** Changed in: libvirt (Ubuntu Focal) Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1890858 Title: AppArmor profile causes QEMU/KVM - Not Connected Status in apparmor package in Ubuntu: Invalid Status in libvirt package in Ubuntu: Invalid Status in apparmor source package in Focal: New Status in libvirt source package in Focal: Triaged Bug description: [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 "*;*;*;Al-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/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1890858/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.lau
