From: intrigeri@riseup.net   
      
   Hi,   
      
   Simon McVittie (2026-02-22):   
   > I'm now questioning whether the benefit of the AppArmor profile is worth    
   > its cost.   
      
   Thank you for asking and thanks a lot for the summary!   
      
   This resonates a lot: in the last few years I've been leaning more and   
   more towards answering "no". I think it might be time to let go and   
   drop the AppArmor profiles that have a non-trivial maintenance cost,   
   while comparatively providing little¹ meaningful security benefit.   
      
   If maintainers choose to drop this kind of AppArmor profiles from   
   their packages, I will understand and fully support their decision.   
      
   [1] I'm writing "little" and not "no" because I'm not 100% convinced   
       these sandbox escapes make the profiles entirely useless:   
       I understand the existing policy raises the bar from "I've   
       exploited poppler, now I have arbitrary code execution" to "I've   
       exploited poppler, now I need to figure out which sort of sandbox   
       the apps that uses the library is running in, and I have to   
       implement the adequate sandbox escape". I suppose some adversaries   
       are happy to pay this cost if this gives them access to high-value   
       targets, who are known to use a given app or OS, so they'll   
       happily adjust their exploit accordingly; while for some other   
       adversaries, it's not worth the effort, considering all the less   
       protected targets that are available elsewhere.   
      
      
   For extra context, my previous hopes for using AppArmor for meaningful   
   confinement of desktop apps, and in particular GTK apps since I've   
   been focused on those much more closely, were based on the hope that   
   a few things would happen quickly enough. Off the top of my head, this   
   included:   
      
    - Fine-grained D-Bus confinement becomes available at a time when   
      there's a healthy dynamics to collaboratively maintain AppArmor   
      policy cross-distro.   
      
      (D-Bus support is finally coming, hopefully in Forky. And for   
      policy maintenance, https://github.com/roddhjav/apparmor.d/ is the   
      new thing that gives me some hope back, but it's a huge and complex   
      beast, I don't know if anyone has figured out how to use this as   
      a distribution.)   
      
    - GTK apps installed from Debian can be easily instructed to behave   
      essentially as if they were running via Flatpak, i.e. using Portals   
      for everything relevant, no direct dconf access, etc., so that we   
      can ship much stricter AppArmor policy in Debian packages.   
      
      (We've experimented with the idea in Tails, starting with the   
      obvious GTK_USE_PORTAL=1, quickly faced limitations that were   
      blockers for us, and ended up running some apps as "fake" Flatpak   
      apps with flatpak-run(1), using our underlying SquashFS as the   
      runtime. This hack works fine for our particular use case, but it's   
      probably not worth generalizing to a context like Debian.   
      
      I'm not complaining: I did not invest any effort into resolving the   
      root causes in GNOME land. My guess is that there would be little   
      interest upstream, and frankly, I find the expected rebuttal pretty   
      convincing: "why don't you just install the app from   
      Flathub then?")   
      
    - Safer accessibility frameworks become the norm   
      
    - AppArmor being enabled by default in Debian raises interest in   
      working on things like the above, as a way to protect our users   
      better, while sparing us the discussion, design & implementation   
      work required to change in depth how we distribute apps.   
      
      
   Cheers,   
   --    
   intrigeri   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)