[pkg-apparmor] Interest in backporting AppArmor 5 to Trixie once released?

[Aaron Rainbolt]

On Thu, 09 Apr 2026 11:53:02 +0200
intrigeri <intrigeri at debian.org> wrote:

> Hi Aaron,
> 
> intrigeri (2026-04-01):
> > Aaron Rainbolt (2026-03-31):  
> >> On Tue, 31 Mar 2026 13:43:20 +0200
> >> intrigeri <intrigeri at debian.org> wrote:  
> 
> >>>  - Help with the current Glycin + bwrap vs. AppArmor mess
> >>>    (starting point: #1127935, I can provide more context and
> >>> point to what I think would be the best solution, if desired; the
> >>> next item on this list can also help determine how much effort
> >>> this is worth)  
> >>
> >> That looks interesting. Whonix currently uses loupe as our image
> >> viewer specifically because it uses Glycin which provides
> >> sandboxed rendering, so getting that working right upstream sounds
> >> like something we should do.  
> >
> > OK, then this would be, by far, the best way to support my AppArmor
> > work at the moment, as it's the hottest topic, probably needs a few
> > hours of work, and I don't seem to find them.
> >
> > The way I would approach it would be to provide a set of profiles
> > that apps profile can use for this. I would start from
> > https://github.com/roddhjav/apparmor.d/tree/main/apparmor.d/namespaces/glycin,
> > i.e. the namespace version of their solution, that works for
> > processes even if they have NNP set, and adjust this as needed for
> > usage outside of roddhjav/apparmor.d.
> >
> > For inspiration, I've done something similar already there, albeit
> > without using the namespace version (which only works for processes
> > that don't have NNP set):
> > https://gitlab.torproject.org/tpo/applications/torbrowser-launcher/-/merge_requests/42
> >
> > I would propose this new set of profiles upstream and backport to
> > Debian. I would use different profile & file names from
> > roddhjav/apparmor.d's to avoid conflicts.
> >
> > For more context, background, and inspiration:
> >
> >  - https://apparmor.pujol.io/development/internal/#no-new-privileges
> >  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1127671
> >  - https://github.com/roddhjav/apparmor.d/issues/881
> >  -
> > https://salsa.debian.org/gnome-team/extras/evince/-/merge_requests/10
> >  
> 
> Did you get an opportunity to look into this?
> 
> Cheers,

A quick update on where I'm at so far; I was able to extract the
Glycin-related apparmor.d profiles into a dedicated abstractions/glycin
mechanism that works on LibreOffice and Evince on Debian Testing.
Currently roddhjav (apparmor.d's maintainer) is helping me get the
profiles into a state both of us are happy with so they can be
upstreamed into AppArmor itself. I should have an MR to upstream
*possibly* before the end of the month, depending on how things go.
Once that's upstreamed, I'll package the patch and submit it for your
review (and I'll keep you in the loop once I get an MR made).

Patrick (adrelanos) and I discussed using an AppArmor 5 backport in
Whonix in the future, and even though this email started with a backport
request, I think we actually won't (at least immediately) use one if it
were to happen. Neither me nor Patrick expected that there could be
compatibility issues that ABI declarations in AppArmor profiles couldn't
work around, and we don't want to maintain modified AppArmor profiles
for apps we don't maintain downstream. That being said, we are still
interested in helping with maintenance since AppArmor is very useful to
us and we'll want things to work smoothly in Debian 14 and beyond.
Also, apparmor.d seems to be expecting a backport to exist at some
point (see the end of
https://github.com/roddhjav/apparmor.d/issues/967), so it might still
be worthwhile.

--
Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-apparmor-team/attachments/20260423/8e7e620b/attachment.sig>