Activity log for bug #2056739

Date Who What changed Old value New value Message
2024-03-11 08:48:05 Martin Pitt bug added bug
2024-03-11 08:48:19 Martin Pitt nominated for series Ubuntu Noble
2024-03-11 08:48:19 Martin Pitt bug task added libvirt (Ubuntu Noble)
2024-03-11 08:48:29 Martin Pitt tags noble regression-release cockpit-test noble regression-release
2024-03-11 10:50:43 Christian Ehrhardt  bug task added chrony (Ubuntu)
2024-03-11 10:51:09 Christian Ehrhardt  description Running any VM in libvirt causes a new AppArmor violation in current noble. This is a regression, this didn't happen in any previous release. Reproducer: virt-install --memory 50 --pxe --virt-type qemu --os-variant alpinelinux3.8 --disk none --wait 0 --name test1 (This is the simplest way to create a test VM. But it's form or shape doesn't matter at all). Results in lots of audit: type=1400 audit(1710146677.570:108): apparmor="DENIED" operation="open" class="file" profile="virt-aa-helper" name="/etc/gnutls/config" pid=1480 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 libvirt-daemon 10.0.0-2ubuntu1 apparmor 4.0.0~alpha4-0ubuntu1 libgnutls30:amd64 3.8.3-1ubuntu1 --- --- Merely booting current noble cloud image with "chrony" installed causes this: audit: type=1400 audit(1710152842.540:107): apparmor="DENIED" operation="open" class="file" profile="/usr/sbin/chronyd" name="/etc/gnutls/config" pid=878 comm="chronyd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 --- --- Running any VM in libvirt causes a new AppArmor violation in current noble. This is a regression, this didn't happen in any previous release. Reproducer:   virt-install --memory 50 --pxe --virt-type qemu --os-variant alpinelinux3.8 --disk none --wait 0 --name test1 (This is the simplest way to create a test VM. But it's form or shape doesn't matter at all). Results in lots of audit: type=1400 audit(1710146677.570:108): apparmor="DENIED" operation="open" class="file" profile="virt-aa-helper" name="/etc/gnutls/config" pid=1480 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 libvirt-daemon 10.0.0-2ubuntu1 apparmor 4.0.0~alpha4-0ubuntu1 libgnutls30:amd64 3.8.3-1ubuntu1
2024-03-11 10:57:30 Christian Ehrhardt  description --- --- Merely booting current noble cloud image with "chrony" installed causes this: audit: type=1400 audit(1710152842.540:107): apparmor="DENIED" operation="open" class="file" profile="/usr/sbin/chronyd" name="/etc/gnutls/config" pid=878 comm="chronyd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 --- --- Running any VM in libvirt causes a new AppArmor violation in current noble. This is a regression, this didn't happen in any previous release. Reproducer:   virt-install --memory 50 --pxe --virt-type qemu --os-variant alpinelinux3.8 --disk none --wait 0 --name test1 (This is the simplest way to create a test VM. But it's form or shape doesn't matter at all). Results in lots of audit: type=1400 audit(1710146677.570:108): apparmor="DENIED" operation="open" class="file" profile="virt-aa-helper" name="/etc/gnutls/config" pid=1480 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 libvirt-daemon 10.0.0-2ubuntu1 apparmor 4.0.0~alpha4-0ubuntu1 libgnutls30:amd64 3.8.3-1ubuntu1 Christian summarizes this after the great reports by Martin: gnutls started to ship forceful disables in pkg/import/3.8.1-4ubuntu3 and added more later. Due to that anything linked against gnutls while being apparmor isolated now hits similar denials, preventing the desired effect of the config change BTW. I think for safety we WANT to always allow this access, otherwise people will subtly not have crypto control about the more important (those isolated) software. Because after the denial I'd expect this to not really disable it in the program linked to gnutls (details might vary depending what they really use gnutls for). I do not nkow of a gnutls abstraction to use, but TBH I'm afraid now fixing a few but leaving this open in some others not spotted. I'd therefore suggest, but we need to discuss, to therefore change it in /etc/apparmor.d/abstractions/base. Therefore I'm adding gnutls (and Adrien) as well as apparmor to the bug tasks. --- --- Merely booting current noble cloud image with "chrony" installed causes this: audit: type=1400 audit(1710152842.540:107): apparmor="DENIED" operation="open" class="file" profile="/usr/sbin/chronyd" name="/etc/gnutls/config" pid=878 comm="chronyd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 --- --- Running any VM in libvirt causes a new AppArmor violation in current noble. This is a regression, this didn't happen in any previous release. Reproducer:   virt-install --memory 50 --pxe --virt-type qemu --os-variant alpinelinux3.8 --disk none --wait 0 --name test1 (This is the simplest way to create a test VM. But it's form or shape doesn't matter at all). Results in lots of audit: type=1400 audit(1710146677.570:108): apparmor="DENIED" operation="open" class="file" profile="virt-aa-helper" name="/etc/gnutls/config" pid=1480 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 libvirt-daemon 10.0.0-2ubuntu1 apparmor 4.0.0~alpha4-0ubuntu1 libgnutls30:amd64 3.8.3-1ubuntu1
2024-03-11 10:57:42 Christian Ehrhardt  bug task added gnutls28 (Ubuntu)
2024-03-11 10:57:48 Christian Ehrhardt  bug task added apparmor (Ubuntu)
2024-03-11 10:57:57 Christian Ehrhardt  bug added subscriber Adrien Nader
2024-03-11 10:58:36 Christian Ehrhardt  description Christian summarizes this after the great reports by Martin: gnutls started to ship forceful disables in pkg/import/3.8.1-4ubuntu3 and added more later. Due to that anything linked against gnutls while being apparmor isolated now hits similar denials, preventing the desired effect of the config change BTW. I think for safety we WANT to always allow this access, otherwise people will subtly not have crypto control about the more important (those isolated) software. Because after the denial I'd expect this to not really disable it in the program linked to gnutls (details might vary depending what they really use gnutls for). I do not nkow of a gnutls abstraction to use, but TBH I'm afraid now fixing a few but leaving this open in some others not spotted. I'd therefore suggest, but we need to discuss, to therefore change it in /etc/apparmor.d/abstractions/base. Therefore I'm adding gnutls (and Adrien) as well as apparmor to the bug tasks. --- --- Merely booting current noble cloud image with "chrony" installed causes this: audit: type=1400 audit(1710152842.540:107): apparmor="DENIED" operation="open" class="file" profile="/usr/sbin/chronyd" name="/etc/gnutls/config" pid=878 comm="chronyd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 --- --- Running any VM in libvirt causes a new AppArmor violation in current noble. This is a regression, this didn't happen in any previous release. Reproducer:   virt-install --memory 50 --pxe --virt-type qemu --os-variant alpinelinux3.8 --disk none --wait 0 --name test1 (This is the simplest way to create a test VM. But it's form or shape doesn't matter at all). Results in lots of audit: type=1400 audit(1710146677.570:108): apparmor="DENIED" operation="open" class="file" profile="virt-aa-helper" name="/etc/gnutls/config" pid=1480 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 libvirt-daemon 10.0.0-2ubuntu1 apparmor 4.0.0~alpha4-0ubuntu1 libgnutls30:amd64 3.8.3-1ubuntu1 Christian summarizes this after the great reports by Martin: gnutls started to ship forceful disables in pkg/import/3.8.1-4ubuntu3 and added more later. Due to that anything linked against gnutls while being apparmor isolated now hits similar denials, preventing the desired effect of the config change BTW. I think for safety we WANT to always allow this access, otherwise people will subtly not have crypto control about the more important (those isolated) software. Because after the denial I'd expect this to not really disable it in the program linked to gnutls (details might vary depending what they really use gnutls for). I do not nkow of a gnutls abstraction to use, but TBH I'm afraid now fixing a few but leaving this open in some others not spotted. I'd therefore suggest, but we need to discuss, to therefore change it in /etc/apparmor.d/abstractions/base. Therefore I'm adding gnutls (and Adrien) as well as apparmor to the bug tasks. --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Merely booting current noble cloud image with "chrony" installed causes this: audit: type=1400 audit(1710152842.540:107): apparmor="DENIED" operation="open" class="file" profile="/usr/sbin/chronyd" name="/etc/gnutls/config" pid=878 comm="chronyd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Running any VM in libvirt causes a new AppArmor violation in current noble. This is a regression, this didn't happen in any previous release. Reproducer:   virt-install --memory 50 --pxe --virt-type qemu --os-variant alpinelinux3.8 --disk none --wait 0 --name test1 (This is the simplest way to create a test VM. But it's form or shape doesn't matter at all). Results in lots of audit: type=1400 audit(1710146677.570:108): apparmor="DENIED" operation="open" class="file" profile="virt-aa-helper" name="/etc/gnutls/config" pid=1480 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 libvirt-daemon 10.0.0-2ubuntu1 apparmor 4.0.0~alpha4-0ubuntu1 libgnutls30:amd64 3.8.3-1ubuntu1
2024-03-11 12:53:08 Launchpad Janitor merge proposal linked https://code.launchpad.net/~paelzer/ubuntu/+source/apparmor/+git/apparmor/+merge/462142
2024-03-12 08:01:37 Christian Ehrhardt  bug added subscriber John Johansen
2024-03-12 08:02:23 Christian Ehrhardt  libvirt (Ubuntu Noble): status New Won't Fix
2024-03-12 08:02:26 Christian Ehrhardt  gnutls28 (Ubuntu Noble): status New Won't Fix
2024-03-12 08:02:29 Christian Ehrhardt  chrony (Ubuntu Noble): status New Won't Fix
2024-03-12 08:02:32 Christian Ehrhardt  apparmor (Ubuntu Noble): status New In Progress
2024-03-12 08:18:39 Martin Pitt chrony (Ubuntu): status New Won't Fix
2024-03-12 08:18:42 Martin Pitt gnutls28 (Ubuntu): status New Won't Fix
2024-03-12 08:18:46 Martin Pitt libvirt (Ubuntu): status New Won't Fix
2024-03-13 06:38:52 Christian Ehrhardt  chrony (Ubuntu): assignee John Johansen (jjohansen)
2024-03-28 03:41:24 Launchpad Janitor apparmor (Ubuntu Noble): status In Progress Fix Released