| 2024-06-01 20:53:44 |
L W R |
bug |
|
|
added bug |
| 2024-06-02 13:34:02 |
Andreas Hasenack |
bug |
|
|
added subscriber Andreas Hasenack |
| 2024-06-03 13:54:34 |
Andreas Hasenack |
bug watch added |
|
https://github.com/canonical/ubuntu-pro-client/issues/3137 |
|
| 2024-06-06 03:00:40 |
Renan Rodrigo |
ubuntu-advantage-tools (Ubuntu): status |
New |
In Progress |
|
| 2024-06-06 03:00:53 |
Renan Rodrigo |
ubuntu-advantage-tools (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2024-06-07 18:06:45 |
Andreas Hasenack |
description |
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
[ Impact ]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
|
| 2024-06-07 18:06:56 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Xenial |
|
| 2024-06-07 18:06:56 |
Andreas Hasenack |
bug task added |
|
ubuntu-advantage-tools (Ubuntu Xenial) |
|
| 2024-06-07 18:06:56 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Bionic |
|
| 2024-06-07 18:06:56 |
Andreas Hasenack |
bug task added |
|
ubuntu-advantage-tools (Ubuntu Bionic) |
|
| 2024-06-07 18:06:56 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Oracular |
|
| 2024-06-07 18:06:56 |
Andreas Hasenack |
bug task added |
|
ubuntu-advantage-tools (Ubuntu Oracular) |
|
| 2024-06-07 18:06:56 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Mantic |
|
| 2024-06-07 18:06:56 |
Andreas Hasenack |
bug task added |
|
ubuntu-advantage-tools (Ubuntu Mantic) |
|
| 2024-06-07 18:06:56 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Noble |
|
| 2024-06-07 18:06:56 |
Andreas Hasenack |
bug task added |
|
ubuntu-advantage-tools (Ubuntu Noble) |
|
| 2024-06-07 18:06:56 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Jammy |
|
| 2024-06-07 18:06:56 |
Andreas Hasenack |
bug task added |
|
ubuntu-advantage-tools (Ubuntu Jammy) |
|
| 2024-06-07 18:06:56 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Focal |
|
| 2024-06-07 18:06:56 |
Andreas Hasenack |
bug task added |
|
ubuntu-advantage-tools (Ubuntu Focal) |
|
| 2024-06-07 18:07:05 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Xenial): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2024-06-07 18:07:07 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Bionic): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2024-06-07 18:07:09 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Focal): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2024-06-07 18:07:11 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Jammy): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2024-06-07 18:07:13 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Mantic): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2024-06-07 18:07:15 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Noble): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2024-06-07 18:07:20 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Xenial): status |
New |
In Progress |
|
| 2024-06-07 18:07:22 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Bionic): status |
New |
In Progress |
|
| 2024-06-07 18:07:23 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Focal): status |
New |
In Progress |
|
| 2024-06-07 18:07:26 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Jammy): status |
New |
In Progress |
|
| 2024-06-07 18:07:28 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Mantic): status |
New |
In Progress |
|
| 2024-06-07 18:07:30 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Noble): status |
New |
In Progress |
|
| 2024-06-07 18:07:32 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2024-06-07 18:07:34 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2024-06-07 18:07:36 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Focal): importance |
Undecided |
Medium |
|
| 2024-06-07 18:07:37 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Jammy): importance |
Undecided |
Medium |
|
| 2024-06-07 18:07:39 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Mantic): importance |
Undecided |
Medium |
|
| 2024-06-07 18:07:41 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Noble): importance |
Undecided |
Medium |
|
| 2024-06-07 18:07:42 |
Andreas Hasenack |
ubuntu-advantage-tools (Ubuntu Oracular): importance |
Undecided |
Medium |
|
| 2024-06-07 18:14:28 |
Andreas Hasenack |
description |
[ Impact ]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
The upstream test suite has been run with the bug trigger in place, and no tests have been found that would fail because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
|
| 2024-06-07 18:20:18 |
Andreas Hasenack |
description |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
The upstream test suite has been run with the bug trigger in place, and no tests have been found that would fail because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
- install the Pro client version to be tested
-
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
|
| 2024-06-07 18:44:11 |
Andreas Hasenack |
description |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
- install the Pro client version to be tested
-
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue
- install the Pro client version to be tested
- run these commands:
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test
- install the Pro client version to be tested
- run these commands in sequence as root:
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
|
| 2024-06-07 18:51:01 |
Andreas Hasenack |
description |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue
- install the Pro client version to be tested
- run these commands:
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test
- install the Pro client version to be tested
- run these commands in sequence as root:
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue
- install the Pro client version to be tested
- run these commands:
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test
- install the Pro client version to be tested
- run these commands in sequence as root:
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
Upstream bug report: https://github.com/canonical/ubuntu-pro-client/issues/3137
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
|
| 2024-06-07 18:56:25 |
Andreas Hasenack |
description |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue
- install the Pro client version to be tested
- run these commands:
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test
- install the Pro client version to be tested
- run these commands in sequence as root:
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
Upstream bug report: https://github.com/canonical/ubuntu-pro-client/issues/3137
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue
- install the Pro client version to be tested
- run these commands:
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test
- install the Pro client version to be tested
- run these commands in sequence as root:
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
A syntax error in the apparmor profile would prevent it from loading, and remove its protection entirely. To account for that, the package build process runs an apparmor static check on the generated profiles, and if that fails, the package build fails. It could still be susceptible to errors at profile load-time regarding the running kernel, which is likely different than the running kernel in the launchpad builders.
Another type of mistake that could happen is inadvertently opening up the profile more than is needed. But the extra access we are giving here is read-only, and the affected profiles do need that access.
[ Other Info ]
Upstream bug report: https://github.com/canonical/ubuntu-pro-client/issues/3137
Unfortunately this wasn't caught by the extensive Pro test suite because the test units (vms, lxd containers) never had a /var/lib/dpkg/arch file in them. Likewise, the development container where this profile was first created also didn't have that file.
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
|
| 2024-06-10 12:39:21 |
Andreas Hasenack |
description |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue
- install the Pro client version to be tested
- run these commands:
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test
- install the Pro client version to be tested
- run these commands in sequence as root:
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
A syntax error in the apparmor profile would prevent it from loading, and remove its protection entirely. To account for that, the package build process runs an apparmor static check on the generated profiles, and if that fails, the package build fails. It could still be susceptible to errors at profile load-time regarding the running kernel, which is likely different than the running kernel in the launchpad builders.
Another type of mistake that could happen is inadvertently opening up the profile more than is needed. But the extra access we are giving here is read-only, and the affected profiles do need that access.
[ Other Info ]
Upstream bug report: https://github.com/canonical/ubuntu-pro-client/issues/3137
Unfortunately this wasn't caught by the extensive Pro test suite because the test units (vms, lxd containers) never had a /var/lib/dpkg/arch file in them. Likewise, the development container where this profile was first created also didn't have that file.
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue
- install the Pro client version to be tested
- if you don't have a /var/lib/dpkg/arch file, create it with this command:
sudo touch /var/lib/dpkg/arch
- then run these commands:
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test
- install the Pro client version to be tested
- run these commands in sequence as root:
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
A syntax error in the apparmor profile would prevent it from loading, and remove its protection entirely. To account for that, the package build process runs an apparmor static check on the generated profiles, and if that fails, the package build fails. It could still be susceptible to errors at profile load-time regarding the running kernel, which is likely different than the running kernel in the launchpad builders.
Another type of mistake that could happen is inadvertently opening up the profile more than is needed. But the extra access we are giving here is read-only, and the affected profiles do need that access.
[ Other Info ]
Upstream bug report: https://github.com/canonical/ubuntu-pro-client/issues/3137
Unfortunately this wasn't caught by the extensive Pro test suite because the test units (vms, lxd containers) never had a /var/lib/dpkg/arch file in them. Likewise, the development container where this profile was first created also didn't have that file.
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
|
| 2024-06-10 16:00:58 |
Andreas Hasenack |
description |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue
- install the Pro client version to be tested
- if you don't have a /var/lib/dpkg/arch file, create it with this command:
sudo touch /var/lib/dpkg/arch
- then run these commands:
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test
- install the Pro client version to be tested
- run these commands in sequence as root:
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
A syntax error in the apparmor profile would prevent it from loading, and remove its protection entirely. To account for that, the package build process runs an apparmor static check on the generated profiles, and if that fails, the package build fails. It could still be susceptible to errors at profile load-time regarding the running kernel, which is likely different than the running kernel in the launchpad builders.
Another type of mistake that could happen is inadvertently opening up the profile more than is needed. But the extra access we are giving here is read-only, and the affected profiles do need that access.
[ Other Info ]
Upstream bug report: https://github.com/canonical/ubuntu-pro-client/issues/3137
Unfortunately this wasn't caught by the extensive Pro test suite because the test units (vms, lxd containers) never had a /var/lib/dpkg/arch file in them. Likewise, the development container where this profile was first created also didn't have that file.
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue. Needs to be run in a VM, not LXD, otherwise apparmor will block /dev/pts/* which affects this test (but does not affect the esm-cache.service -- see test (b))
- install the Pro client version to be tested
- run these commands:
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test
- install the Pro client version to be tested
- run these commands in sequence as root:
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
A syntax error in the apparmor profile would prevent it from loading, and remove its protection entirely. To account for that, the package build process runs an apparmor static check on the generated profiles, and if that fails, the package build fails. It could still be susceptible to errors at profile load-time regarding the running kernel, which is likely different than the running kernel in the launchpad builders.
Another type of mistake that could happen is inadvertently opening up the profile more than is needed. But the extra access we are giving here is read-only, and the affected profiles do need that access.
[ Other Info ]
Upstream bug report: https://github.com/canonical/ubuntu-pro-client/issues/3137
Unfortunately this wasn't caught by the extensive Pro test suite because the test units (vms, lxd containers) never had a /var/lib/dpkg/arch file in them. Likewise, the development container where this profile was first created also didn't have that file.
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
|
| 2024-06-10 16:02:29 |
Andreas Hasenack |
description |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue. Needs to be run in a VM, not LXD, otherwise apparmor will block /dev/pts/* which affects this test (but does not affect the esm-cache.service -- see test (b))
- install the Pro client version to be tested
- run these commands:
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test
- install the Pro client version to be tested
- run these commands in sequence as root:
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
A syntax error in the apparmor profile would prevent it from loading, and remove its protection entirely. To account for that, the package build process runs an apparmor static check on the generated profiles, and if that fails, the package build fails. It could still be susceptible to errors at profile load-time regarding the running kernel, which is likely different than the running kernel in the launchpad builders.
Another type of mistake that could happen is inadvertently opening up the profile more than is needed. But the extra access we are giving here is read-only, and the affected profiles do need that access.
[ Other Info ]
Upstream bug report: https://github.com/canonical/ubuntu-pro-client/issues/3137
Unfortunately this wasn't caught by the extensive Pro test suite because the test units (vms, lxd containers) never had a /var/lib/dpkg/arch file in them. Likewise, the development container where this profile was first created also didn't have that file.
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue. Needs to be run in a VM, not LXD, otherwise apparmor will block /dev/pts/* which affects this test (but does not affect the esm-cache.service -- see test (b))
- install the Pro client version to be tested
- run these commands:
sudo touch /var/lib/dpkg/arch
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test
- install the Pro client version to be tested
- run these commands in sequence as root:
sudo touch /var/lib/dpkg/arch
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
A syntax error in the apparmor profile would prevent it from loading, and remove its protection entirely. To account for that, the package build process runs an apparmor static check on the generated profiles, and if that fails, the package build fails. It could still be susceptible to errors at profile load-time regarding the running kernel, which is likely different than the running kernel in the launchpad builders.
Another type of mistake that could happen is inadvertently opening up the profile more than is needed. But the extra access we are giving here is read-only, and the affected profiles do need that access.
[ Other Info ]
Upstream bug report: https://github.com/canonical/ubuntu-pro-client/issues/3137
Unfortunately this wasn't caught by the extensive Pro test suite because the test units (vms, lxd containers) never had a /var/lib/dpkg/arch file in them. Likewise, the development container where this profile was first created also didn't have that file.
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
|
| 2024-06-10 16:03:05 |
Andreas Hasenack |
description |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue. Needs to be run in a VM, not LXD, otherwise apparmor will block /dev/pts/* which affects this test (but does not affect the esm-cache.service -- see test (b))
- install the Pro client version to be tested
- run these commands:
sudo touch /var/lib/dpkg/arch
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test
- install the Pro client version to be tested
- run these commands in sequence as root:
sudo touch /var/lib/dpkg/arch
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
A syntax error in the apparmor profile would prevent it from loading, and remove its protection entirely. To account for that, the package build process runs an apparmor static check on the generated profiles, and if that fails, the package build fails. It could still be susceptible to errors at profile load-time regarding the running kernel, which is likely different than the running kernel in the launchpad builders.
Another type of mistake that could happen is inadvertently opening up the profile more than is needed. But the extra access we are giving here is read-only, and the affected profiles do need that access.
[ Other Info ]
Upstream bug report: https://github.com/canonical/ubuntu-pro-client/issues/3137
Unfortunately this wasn't caught by the extensive Pro test suite because the test units (vms, lxd containers) never had a /var/lib/dpkg/arch file in them. Likewise, the development container where this profile was first created also didn't have that file.
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue. Needs to be run in a VM, not LXD, otherwise apparmor will block /dev/pts/* which affects this test (but does not affect the esm-cache.service -- see test (b))
- install the Pro client version to be tested
- run these commands:
sudo touch /var/lib/dpkg/arch
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test
- install the Pro client version to be tested
- run these commands in sequence as root:
touch /var/lib/dpkg/arch
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
A syntax error in the apparmor profile would prevent it from loading, and remove its protection entirely. To account for that, the package build process runs an apparmor static check on the generated profiles, and if that fails, the package build fails. It could still be susceptible to errors at profile load-time regarding the running kernel, which is likely different than the running kernel in the launchpad builders.
Another type of mistake that could happen is inadvertently opening up the profile more than is needed. But the extra access we are giving here is read-only, and the affected profiles do need that access.
[ Other Info ]
Upstream bug report: https://github.com/canonical/ubuntu-pro-client/issues/3137
Unfortunately this wasn't caught by the extensive Pro test suite because the test units (vms, lxd containers) never had a /var/lib/dpkg/arch file in them. Likewise, the development container where this profile was first created also didn't have that file.
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
|
| 2024-06-10 16:30:06 |
Andreas Hasenack |
description |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue. Needs to be run in a VM, not LXD, otherwise apparmor will block /dev/pts/* which affects this test (but does not affect the esm-cache.service -- see test (b))
- install the Pro client version to be tested
- run these commands:
sudo touch /var/lib/dpkg/arch
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test
- install the Pro client version to be tested
- run these commands in sequence as root:
touch /var/lib/dpkg/arch
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
A syntax error in the apparmor profile would prevent it from loading, and remove its protection entirely. To account for that, the package build process runs an apparmor static check on the generated profiles, and if that fails, the package build fails. It could still be susceptible to errors at profile load-time regarding the running kernel, which is likely different than the running kernel in the launchpad builders.
Another type of mistake that could happen is inadvertently opening up the profile more than is needed. But the extra access we are giving here is read-only, and the affected profiles do need that access.
[ Other Info ]
Upstream bug report: https://github.com/canonical/ubuntu-pro-client/issues/3137
Unfortunately this wasn't caught by the extensive Pro test suite because the test units (vms, lxd containers) never had a /var/lib/dpkg/arch file in them. Likewise, the development container where this profile was first created also didn't have that file.
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue. Needs to be run in a VM, not LXD, otherwise apparmor will block /dev/pts/* which affects this test (but does not affect the esm-cache.service -- see test (b))
- install the Pro client version to be tested
- run these commands:
sudo touch /var/lib/dpkg/arch
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test (only in an LTS)
- install the Pro client version to be tested
- run these commands in sequence as root:
touch /var/lib/dpkg/arch
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
A syntax error in the apparmor profile would prevent it from loading, and remove its protection entirely. To account for that, the package build process runs an apparmor static check on the generated profiles, and if that fails, the package build fails. It could still be susceptible to errors at profile load-time regarding the running kernel, which is likely different than the running kernel in the launchpad builders.
Another type of mistake that could happen is inadvertently opening up the profile more than is needed. But the extra access we are giving here is read-only, and the affected profiles do need that access.
[ Other Info ]
Upstream bug report: https://github.com/canonical/ubuntu-pro-client/issues/3137
Unfortunately this wasn't caught by the extensive Pro test suite because the test units (vms, lxd containers) never had a /var/lib/dpkg/arch file in them. Likewise, the development container where this profile was first created also didn't have that file.
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
|
| 2024-06-10 16:32:57 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/ubuntu-advantage-tools/+git/ubuntu-advantage-tools/+merge/467189 |
|
| 2024-06-10 16:37:08 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/ubuntu-advantage-tools/+git/ubuntu-advantage-tools/+merge/467190 |
|
| 2024-06-10 16:37:36 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/ubuntu-advantage-tools/+git/ubuntu-advantage-tools/+merge/467191 |
|
| 2024-06-10 16:38:04 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/ubuntu-advantage-tools/+git/ubuntu-advantage-tools/+merge/467192 |
|
| 2024-06-10 16:38:29 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/ubuntu-advantage-tools/+git/ubuntu-advantage-tools/+merge/467193 |
|
| 2024-06-10 16:39:04 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/ubuntu-advantage-tools/+git/ubuntu-advantage-tools/+merge/467194 |
|
| 2024-06-10 16:39:30 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/ubuntu-advantage-tools/+git/ubuntu-advantage-tools/+merge/467195 |
|
| 2024-06-15 09:13:54 |
Launchpad Janitor |
ubuntu-advantage-tools (Ubuntu Oracular): status |
In Progress |
Fix Released |
|
| 2024-06-17 13:52:59 |
Andreas Hasenack |
summary |
New Apparmor denial with ubuntu-advantage-tools on bionic |
Apparmor denial on /var/lib/dpkg/arch |
|
| 2024-06-17 22:44:54 |
Mauricio Faria de Oliveira |
ubuntu-advantage-tools (Ubuntu Noble): status |
In Progress |
Fix Committed |
|
| 2024-06-17 22:44:57 |
Mauricio Faria de Oliveira |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-06-17 22:45:00 |
Mauricio Faria de Oliveira |
bug |
|
|
added subscriber SRU Verification |
| 2024-06-17 22:45:04 |
Mauricio Faria de Oliveira |
tags |
|
verification-needed verification-needed-noble |
|
| 2024-06-17 22:46:23 |
Mauricio Faria de Oliveira |
ubuntu-advantage-tools (Ubuntu Mantic): status |
In Progress |
Fix Committed |
|
| 2024-06-17 22:46:29 |
Mauricio Faria de Oliveira |
tags |
verification-needed verification-needed-noble |
verification-needed verification-needed-mantic verification-needed-noble |
|
| 2024-06-17 22:47:10 |
Mauricio Faria de Oliveira |
ubuntu-advantage-tools (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2024-06-17 22:47:16 |
Mauricio Faria de Oliveira |
tags |
verification-needed verification-needed-mantic verification-needed-noble |
verification-needed verification-needed-jammy verification-needed-mantic verification-needed-noble |
|
| 2024-06-17 22:48:25 |
Mauricio Faria de Oliveira |
ubuntu-advantage-tools (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2024-06-17 22:48:32 |
Mauricio Faria de Oliveira |
tags |
verification-needed verification-needed-jammy verification-needed-mantic verification-needed-noble |
verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic verification-needed-noble |
|
| 2024-06-17 22:49:19 |
Mauricio Faria de Oliveira |
ubuntu-advantage-tools (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2024-06-17 22:49:27 |
Mauricio Faria de Oliveira |
tags |
verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic verification-needed-noble |
verification-needed verification-needed-bionic verification-needed-focal verification-needed-jammy verification-needed-mantic verification-needed-noble |
|
| 2024-06-17 22:50:45 |
Mauricio Faria de Oliveira |
ubuntu-advantage-tools (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2024-06-17 22:50:52 |
Mauricio Faria de Oliveira |
tags |
verification-needed verification-needed-bionic verification-needed-focal verification-needed-jammy verification-needed-mantic verification-needed-noble |
verification-needed verification-needed-bionic verification-needed-focal verification-needed-jammy verification-needed-mantic verification-needed-noble verification-needed-xenial |
|
| 2024-06-20 21:14:49 |
Andreas Hasenack |
description |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue. Needs to be run in a VM, not LXD, otherwise apparmor will block /dev/pts/* which affects this test (but does not affect the esm-cache.service -- see test (b))
- install the Pro client version to be tested
- run these commands:
sudo touch /var/lib/dpkg/arch
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test (only in an LTS)
- install the Pro client version to be tested
- run these commands in sequence as root:
touch /var/lib/dpkg/arch
rm -rf /var/lib/apt/periodic/*
service systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
A syntax error in the apparmor profile would prevent it from loading, and remove its protection entirely. To account for that, the package build process runs an apparmor static check on the generated profiles, and if that fails, the package build fails. It could still be susceptible to errors at profile load-time regarding the running kernel, which is likely different than the running kernel in the launchpad builders.
Another type of mistake that could happen is inadvertently opening up the profile more than is needed. But the extra access we are giving here is read-only, and the affected profiles do need that access.
[ Other Info ]
Upstream bug report: https://github.com/canonical/ubuntu-pro-client/issues/3137
Unfortunately this wasn't caught by the extensive Pro test suite because the test units (vms, lxd containers) never had a /var/lib/dpkg/arch file in them. Likewise, the development container where this profile was first created also didn't have that file.
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
[ Impact ]
Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file.
Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command
sudo dpkg --add-architecture i386
That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug.
Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access.
After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU.
[ Test Plan ]
a) very specific test for this issue. Needs to be run in a VM, not LXD, otherwise apparmor will block /dev/pts/* which affects this test (but does not affect the esm-cache.service -- see test (b))
- install the Pro client version to be tested
- run these commands:
sudo touch /var/lib/dpkg/arch
sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures
sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy
Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail)
b) esm-cache.service test (only in an LTS)
- install the Pro client version to be tested
- run these commands in sequence as root:
touch /var/lib/dpkg/arch
rm -rf /var/lib/apt/periodic/*
systemctl start esm-cache.service
Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch.
[ Where problems could occur ]
A syntax error in the apparmor profile would prevent it from loading, and remove its protection entirely. To account for that, the package build process runs an apparmor static check on the generated profiles, and if that fails, the package build fails. It could still be susceptible to errors at profile load-time regarding the running kernel, which is likely different than the running kernel in the launchpad builders.
Another type of mistake that could happen is inadvertently opening up the profile more than is needed. But the extra access we are giving here is read-only, and the affected profiles do need that access.
[ Other Info ]
Upstream bug report: https://github.com/canonical/ubuntu-pro-client/issues/3137
Unfortunately this wasn't caught by the extensive Pro test suite because the test units (vms, lxd containers) never had a /var/lib/dpkg/arch file in them. Likewise, the development container where this profile was first created also didn't have that file.
[ Original Description ]
ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating:
[ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Fix:
--- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200
+++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200
@@ -174,6 +174,8 @@
/etc/dpkg/** r,
+ /var/lib/dpkg/** r,
+
/{,usr/}bin/dpkg mr,
} |
|
| 2024-06-20 21:16:28 |
Andreas Hasenack |
tags |
verification-needed verification-needed-bionic verification-needed-focal verification-needed-jammy verification-needed-mantic verification-needed-noble verification-needed-xenial |
verification-done-noble verification-needed verification-needed-bionic verification-needed-focal verification-needed-jammy verification-needed-mantic verification-needed-xenial |
|
| 2024-06-21 20:48:00 |
Andreas Hasenack |
attachment added |
|
test-dpkg-arch-apparmor https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2067810/+attachment/5791243/+files/test-dpkg-arch-apparmor |
|
| 2024-06-21 20:48:51 |
Andreas Hasenack |
tags |
verification-done-noble verification-needed verification-needed-bionic verification-needed-focal verification-needed-jammy verification-needed-mantic verification-needed-xenial |
verification-done-mantic verification-done-noble verification-needed verification-needed-bionic verification-needed-focal verification-needed-jammy verification-needed-xenial |
|
| 2024-06-21 20:49:28 |
Andreas Hasenack |
tags |
verification-done-mantic verification-done-noble verification-needed verification-needed-bionic verification-needed-focal verification-needed-jammy verification-needed-xenial |
verification-done-jammy verification-done-mantic verification-done-noble verification-needed verification-needed-bionic verification-needed-focal verification-needed-xenial |
|
| 2024-06-21 20:49:57 |
Andreas Hasenack |
tags |
verification-done-jammy verification-done-mantic verification-done-noble verification-needed verification-needed-bionic verification-needed-focal verification-needed-xenial |
verification-done-focal verification-done-jammy verification-done-mantic verification-done-noble verification-needed verification-needed-bionic verification-needed-xenial |
|
| 2024-06-21 22:16:12 |
Andreas Hasenack |
tags |
verification-done-focal verification-done-jammy verification-done-mantic verification-done-noble verification-needed verification-needed-bionic verification-needed-xenial |
verification-done-bionic verification-done-focal verification-done-jammy verification-done-mantic verification-done-noble verification-needed verification-needed-xenial |
|
| 2024-06-21 22:17:31 |
Andreas Hasenack |
attachment added |
|
test-dpkg-arch-apparmor-v2 https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2067810/+attachment/5791266/+files/test-dpkg-arch-apparmor-v2 |
|
| 2024-06-21 22:17:50 |
Andreas Hasenack |
tags |
verification-done-bionic verification-done-focal verification-done-jammy verification-done-mantic verification-done-noble verification-needed verification-needed-xenial |
verification-done-bionic verification-done-focal verification-done-jammy verification-done-mantic verification-done-noble verification-done-xenial verification-needed |
|
| 2024-07-01 09:38:37 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2024-07-01 09:40:52 |
Launchpad Janitor |
ubuntu-advantage-tools (Ubuntu Noble): status |
Fix Committed |
Fix Released |
|
| 2024-07-01 09:48:51 |
Launchpad Janitor |
ubuntu-advantage-tools (Ubuntu Mantic): status |
Fix Committed |
Fix Released |
|
| 2024-07-01 10:00:57 |
Launchpad Janitor |
ubuntu-advantage-tools (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2024-07-01 10:04:36 |
Launchpad Janitor |
ubuntu-advantage-tools (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2024-07-03 05:34:54 |
Launchpad Janitor |
ubuntu-advantage-tools (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2024-07-03 05:35:05 |
Launchpad Janitor |
ubuntu-advantage-tools (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
