[Bug 2064096] Re: Services fail to start in noble deployed with TPM+FDE

Launchpad Bug Tracker 2064096 at bugs.launchpad.net
Wed Jul 10 16:54:41 UTC 2024


This bug was fixed in the package systemd - 256-1ubuntu1

---------------
systemd (256-1ubuntu1) oracular; urgency=medium

  * Merge with Debian unstable. Remaining changes:
    - debian/tests/upstream{,-1,-2}: split upstream tests into two parts
    - debian/tests/tests-in-lxd: run some autopkgtests in LXD too
    - debian/tests/boot-and-services:
      + skip apparmor tests on armhf
      + consume stderr in systemctl status call in test_service
      + drop test_no_failed
    - debian/systemd.postinst:
      + skip daemon-reexec and try-restarts during shutdown
      + manually call systemd-tmpfiles --create in postinst
    - debian/systemd-resolved.postinst: copy existing /etc/resolv.conf to
      /run/systemd/resolve/stub-resolv.conf
    - debian/rules:
      + Remove unneeded efi artifacts on i386 to avoid debugedit errors
    - debian/rules,debian/control,debian/tests/control:
      + Do not build with tpm libraries on i386
      + Do not build with libqrencode on i386
    - debian/gbp.conf,debian/extra/wrap_cl.py:
      Use a customization script to add LP commit links to changelog
    - debian/control:
      + Add Recommends: networkd-dispatcher systemd-resolved to systemd package
      + Give systemd-resolved Priority: important
      + Add Recommends: systemd-hwe-hwdb to udev package
      + Add Breaks: systemd (<< ${binary:Version}) to udev package so that
        systemd is upgraded as well when upgrading udev
      + Make systemd-sysv Depends: on matching version of systemd
      + Drop Recommends: libnss-myhostname libnss-resolve from systemd-resolved
      + Build-Depends: linux-tools-generic
    - d/p/Revert-network-if-sys-is-rw-then-udev-should-be-around.patch:
      Revert "network: if /sys is rw, then udev should be around" upstream
      commit
    - debian/tests/upstream: export QEMU_MEM="1024M" for all tests
    - debian/systemd.links: mask systemd-gpt-auto-generator by default
    - debian/systemd.install: exclude files that are not built for i386
    - debian/systemd.manpages: do not ship un-built manpages on i386
    - debian/tests/control: only install systemd-boot-efi for supported arches
    - test: skip exec-privatenetwork-yes-privatemounts-yes.service in LXC
    - debian/test/unit-tests: skip test-execute on armhf.
  * Dropped changes, included in Debian:
    - debian/extra: use a drop-in resolved.conf to configure Cache=no-negative
    - debian/extra: use a dropin to configure Nice=-1 on systemd-journald.service.
    - debian/extra/systemd-oomd-defaults/-.slice.d/10-oomd-root-slice-defaults.conf:
      Set ManagedOOMSwap=auto, disabling swap kill by default
    - debian/rules:
      + Set default user path
      + Disable LLMNR by default
    - debian/tests/storage: skip tests if scsi_debug module is not available
  * Dropped changes:
    - debian/patches/tmpfiles.d-tmp.conf-make-cleanup-age-30d-on-Ubuntu.patch:
      We want to stay aligned with Debian and upstream instead of keeping this
      30d cleanup.
    - debian/systemd-resolved.install: drop unnecessary delta
    - d/p/debian/UBUNTU-Don-t-override-Ubuntu-s-default-sysctl-values-LP-1962038.patch:
      We do not actually ship sysctld.d/50-default.conf in Debian or Ubuntu.
      When this patch was written, we did, but that change was lost in a merge
      from Debian. The preferred package to set sysctl defaults is procps
      anyways, so rather than restoring sysctl.d/50-default.conf to make this
      patch relevant, drop the patch.
  * New changes:
    - debian/extra: remove systemd-logind.service.d/nice.conf (LP: #2067927)
    - switch-root: use MS_MOVE for /run when switchig from initrd (LP: #2064096)
    - debian/systemd.postinst: do not create /etc/tmpfiles.d/tmp.conf on upgrades.
      We want the upgrades on Ubuntu to be aligned with what a new install
      would look like.

systemd (256-1) unstable; urgency=medium

  [ Kevin Fleming ]
  * Additional workaround for links to legacy /usr/share/systemd/tmp.mount
    placeholder

  [ Yu Watanabe ]
  * debian/extra/network: use NamePolicy=mac only when ID_NET_NAME_MAC is
    set.

  [ Luca Boccassi ]
  * New upstream version 256. For a full list of changes, see:
    https://github.com/systemd/systemd/releases/tag/v256

systemd (256~rc4-1) unstable; urgency=high

  [ Luca Boccassi ]
  * Restart managers on libc-upgrade dpkg trigger (Closes: #1072373)
  * LimitCORE: restore default hard limit to infinity. The intention was
    to change the soft limit, but by default it applies to both unless
    specified, so fix it.
  * New upstream version 256~rc4
  * Drop patches merged upstream

  [ Nick Rosbrook ]
  * debian/extra: set ManagedOOMSwap=auto on -.slice. This has the effect
    of disabling swap kill by default, so cgroups will only be monitored
    for memory pressure, and not swap usage.
  * debian/extra: use a drop-in resolved.conf to configure Cache=no-
    negative. Only ship this on Ubuntu.
  * debian/extra: use a dropin to configure Nice=-1 on systemd-
    journald.service. Only ship this on Ubuntu.

  [ Dan Streetman ]
  * debian/tests/storage: without scsi_debug, skip test

systemd (256~rc3-7) unstable; urgency=medium

  * NEWS: note that any leftover file in /tmp/ will be invisible due to
    the tmpfs and other clarifications (Closes: #1072249)
  * Add pkg.systemd.noukify profile. Will be useful for i386 reduced
    builds
  * d/rules: be more robust against non-existing dirs when deleting files
  * Allow setting GENSYMBOLS_LEVEL from the environment. Needed when
    building with llvm to work around #986746

systemd (256~rc3-6) unstable; urgency=medium

  * NEWS: clarify tmpfiles.d entry (Closes: #1072155)
  * Override false positive Lintian warning
  * Add workaround for links to legacy /usr/share/systemd/tmp.mount
    placeholder. Some users apparently link to the placeholder in
    /usr/share/ so delete any such links, given we don't ship it anymore
    (Closes: #1072187)

 -- Nick Rosbrook <enr0n at ubuntu.com>  Thu, 13 Jun 2024 11:46:06 -0400

** Changed in: systemd (Ubuntu)
       Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/2064096

Title:
  Services fail to start in noble deployed with TPM+FDE

Status in apparmor package in Ubuntu:
  New
Status in cups package in Ubuntu:
  Confirmed
Status in rsyslog package in Ubuntu:
  Confirmed
Status in sssd package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in unbound package in Ubuntu:
  New
Status in apparmor source package in Noble:
  New
Status in cups source package in Noble:
  New
Status in rsyslog source package in Noble:
  New
Status in sssd source package in Noble:
  New
Status in systemd source package in Noble:
  Fix Released
Status in unbound source package in Noble:
  New

Bug description:
  [Impact]

  On systems that have systemd in the initrd, after the switch root,
  services trying to access resources in /run (e.g. /run/systemd/notify)
  will get AppArmor denials. This is because as a part of the switch
  root, before the pivot_root(), the /run (and /proc, /sys, /dev) are
  "moved" with a bind mount. Hence the new /run has a different mount
  id, and AppArmor thinks that e.g. /run/systemd/notify is disconnected
  from the current mount tree.

  [Test Plan]

  The simplest way to test this is to use dracut on a classic Ubuntu
  system:

  1. Create a VM running Ubuntu 24.04 LTS. The virtualization implementation is not important.
  2. Install dracut, and then reboot.

  $ apt install -y dracut

  3. Once rebooted, verify that systemd did a switch root:

  $ journalctl -b --grep "Switching root"

  4. Check for rsyslog AppArmor denials:

  $ dmesg | grep rsyslog

  On an affected system, the denials will be present. With the patch,
  there should be no denials (or at least not related to accessing files
  in /run).

  [Where problems could occur]

  Using MS_MOVE rather than MS_BIND for /run during the switch root means that there is a brief time where /run (in the old root) is not available for units running before the pivot_root(). So, if we were to see problems, it would likely
  be related to problems with resources in /run, very close to the switch root timeframe. However, before noble, the switch root *is* done using MS_MOVE on /run (and /proc, /sys, and /dev), so have reasonable evidence that this is a safe change.

  [Other information]

  We only change the flags for /run because that is the filesystem that
  seems affected in practice. In particular, we leave /proc alone
  because code in systemd may use /proc between the time it is moved to
  the new root, but before the pivot_root(), which would be a riskier
  change.

  [Original Description]

  What's known so far:
  - 24.04 desktop deployed with TPM+FDE shows this bug
  - services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode. And the apparmor profile does already have rules to allow that access
  - only after running aa-disable <path> can the service start fine
  - paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......".
  - When we add rules to the profile using "/systemd/...." (i.e., also dropping the /run prefix), then it works
  - other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism
  - comment #2 also states that azure CVM images are also impacted
  - comment #4 has instructions on how to create such a VM locally with LXD vms

  Original description follows:

  This might be related to #2064088

  The rsyslog service is continually timing out and restarting. If I use
  a service drop-in file and change the 'Type' from 'notify' to
  'simple', the service starts and appears to work normally.

  In the journal, I can see the attached apparmor errors. I can't make
  sense of them, but if it's a similar issue to #2064088, then I suspect
  apparmor is preventing the systemd notify function from alerting
  systemd that the service is up and running.

  ProblemType: Bug
  DistroRelease: Ubuntu 24.04
  Package: rsyslog 8.2312.0-3ubuntu9
  ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
  Uname: Linux 6.8.0-31-generic x86_64
  ApportVersion: 2.28.1-0ubuntu2
  Architecture: amd64
  CasperMD5CheckMismatches: ./boot/grub/grub.cfg
  CasperMD5CheckResult: fail
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Apr 29 10:37:46 2024
  ProcEnviron:
   LANG=en_GB.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=xterm-256color
   XDG_RUNTIME_DIR=<set>
  SourcePackage: rsyslog
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2064096/+subscriptions




More information about the foundations-bugs mailing list