From: smcv@debian.org   
      
   Package: apparmor   
   Version: 4.1.6-2   
   Severity: important   
   Control: affects -1 + src:dbus   
   X-Debbugs-Cc: dbus@packages.debian.org   
      
   In upstream Linux kernels since 6.17, AppArmor supports mediation of   
   D-Bus messages. This works by having the dbus-daemon ask the kernel, for   
   each message, "should I allow this?", to which the kernel responds yes   
   or no according to loaded policies. Before 6.17, Ubuntu carried this as   
   an out-of-tree patch for many years.   
      
   The kernel advertises this capability:   
      
       $ cat /sys/kernel/security/apparmor/features/dbus/mask   
       acquire send receive   
      
   and therefore dbus-daemon thinks it can enforce D-Bus mediation. However,   
   the policy rules don't actually seem to get applied. This results in an   
   autopkgtest failure in dbus on ci.debian.net, on amd64 only (the only   
   architecture where ci.debian.net runs dbus' tests in a qemu VM with a   
   testing/unstable kernel), since late October / early November 2025: the   
   test expects a request to be denied early, but in fact the expected   
   denial is not seen, and eventually the test fails with a timeout.   
      
   To reproduce   
   ============   
      
   (Simplified reproducer)   
      
   Using a virtual machine will be the safest way to do this.   
      
   Tell dbus-daemon that if it cannot enable AppArmor mediation, it should   
   crash out with an error:   
      
       $ cat /etc/dbus-1/system.d/local.conf   
          
      
   Load an AppArmor profile that mediates dbus rules:   
      
       $ cat /etc/apparmor.d/testdbus   
       abi ,   
      
       include    
      
       profile testdbus {   
         include    
         include    
         include    
      
         /usr/bin/dbus-send rmix,   
         audit allow dbus,   
       }   
       $ sudo apparmor-parser -Tr /etc/apparmor.d/testdbus   
      
   (Or use `audit deny dbus`.)   
      
   Run dbus-send under this profile:   
      
   $ sudo aa-exec -p testdbus -d \   
     dbus-send --system --dest=org.freedesktop.systemd1 --print-reply   
   --type=method_call / test.test.test   
      
   (I'm just using systemd as a convenient example of a D-Bus service that   
   is present on relatively minimal systems, substitute anything you want.)   
      
   This works as expected on Ubuntu 24.04 (I used a live image), possibly   
   because their patched kernel differs from the behaviour of Linux 6.17+   
   upstream.   
      
   Expected result   
   ===============   
      
   The system log (systemd Journal or auditd log) reports that dbus-send(1)   
   sent a D-Bus message, and received the reply. Or if `audit deny dbus`   
   was used, the Journal reports that the dbus-daemon prevented the message   
   from being sent, and dbus-send(1) reports an error.   
      
   Or, if the kernel doesn't support dbus message mediation, the   
   dbus-daemon should fail to start, reporting "AppArmor mediation required   
   but not present" (this message comes from bus/apparmor.c in src:dbus).   
      
   Actual result   
   =============   
      
   The message is delivered to systemd (which replies "Error   
   org.freedesktop.DBus.Error.UnknownObject: Unknown object '/'." in this   
   case).   
      
   More complicated test   
   =====================   
      
   The test that is failing is debian/tests/autopkgtest in src:dbus.   
      
   Other notes   
   ===========   
      
   I haven't tried this with apparmor 5.x and , which is not yet   
   available in Debian (Ubuntu has a beta available).   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)