group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <2067810@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package ubuntu-advantage-tools - 32.3.1~16.04

---------------
ubuntu-advantage-tools (32.3.1~16.04) xenial; urgency=medium

  * Adjust the esm_cache apparmor profile to allow reading of dpkg data
    directory (LP: #2067810):
    - d/apparmor/ubuntu_pro_esm_cache.jinja2: allow /var/lib/dpkg/** for dpkg
      and other profiles
    - features/steps/machines.py: trigger the bug in the behave test suite,
      which tests the fix
  * version.py: update version to 32.3.1

 -- Andreas Hasenack <andreas@xxxxxxxxxxxxx>  Fri, 07 Jun 2024 14:52:55
-0300

** Changed in: ubuntu-advantage-tools (Ubuntu Xenial)
       Status: Fix Committed => Fix Released

** Changed in: ubuntu-advantage-tools (Ubuntu Bionic)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/2067810

Title:
  Apparmor denial on /var/lib/dpkg/arch

Status in ubuntu-advantage-tools package in Ubuntu:
  Fix Released
Status in ubuntu-advantage-tools source package in Xenial:
  Fix Released
Status in ubuntu-advantage-tools source package in Bionic:
  Fix Released
Status in ubuntu-advantage-tools source package in Focal:
  Fix Released
Status in ubuntu-advantage-tools source package in Jammy:
  Fix Released
Status in ubuntu-advantage-tools source package in Mantic:
  Fix Released
Status in ubuntu-advantage-tools source package in Noble:
  Fix Released
Status in ubuntu-advantage-tools source package in Oracular:
  Fix Released

Bug 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/*
    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,

     }

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2067810/+subscriptions