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

[John Johansen]

Does the profile have the attach_disconnected flag set?

Does the profile have the attach_disconnected flag set while in complain
mode?

It looks to me that we are looking at open file descriptors that exist
out of the current namespace. This will result in a partial unattached
path that will not be allowed in complain mode. The denied path will not
start with /.

If the attach_disconnected flag is add, that will attach the
disconnected path to the root of the current mount namespace.  Which is
what I believe is happening with

  /systemd/...
vs
  /run/systemd/......".


Unless unconfined is involved, both the ends of a socket are required to exist in the namespace for v7/v8 unix socket mediation (what is in noble). Unconfined is special in that it can delegate access to an open fd which is not generically allowed atm.

If all the above is correct then you can use the
attach_disconnected.path flag to attach the accesses to disconnected
fds.

The full flags parameter to apparmor would then look like

  profile example flags=(attach_disonnected
attach_disconnected.path=/run/) { ...)

and for complain mode

  profile example flags=(complain attach_disonnected
attach_disconnected.path=/run/) { ...)


This of course is a less than satisfactory work around. There is work to address the above better but none of it is in noble.

-- 
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:
  New

Bug 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