** Description changed:
+ 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
** Also affects: gnutls28 (Ubuntu)
Importance: Undecided
Status: New
** Also affects: apparmor (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
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:
+ --- --- --- --- --- --- --- --- --- --- --- ---
+ --- --- --- --- --- --- --- --- --- --- --- ---
+
+
+ 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.
+ --- --- --- --- --- --- --- --- --- --- --- ---
+ --- --- --- --- --- --- --- --- --- --- --- ---
+
+
+ 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
--
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/2056739
Title:
apparmor="DENIED" operation="open" class="file" profile="virt-aa-
helper" name="/etc/gnutls/config"
Status in apparmor package in Ubuntu:
New
Status in chrony package in Ubuntu:
New
Status in gnutls28 package in Ubuntu:
New
Status in libvirt package in Ubuntu:
New
Status in apparmor source package in Noble:
New
Status in chrony source package in Noble:
New
Status in gnutls28 source package in Noble:
New
Status in libvirt source package in Noble:
New
Bug 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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2056739/+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
