Each time I run libreoffice, I now get:

WARNING: Glycin running without sandbox.
WARNING: Glycin running without sandbox.

If there is such a warning, I suppose that this is because
there is a major security issue with it (otherwise, the user
should not be annoyed with that).

I see the same warning (over and over, tens of times a second) when I
start thunderbird 1:140.7.1esr-1+b1. Additionally, thunderbird crashes
when I try to attach a file to a message with a glycin-related error
message.

Greetings
Marc

I see the same warning (over and over, tens of times a second) when I
start thunderbird 1:140.7.1esr-1+b1. Additionally, thunderbird crashes
when I try to attach a file to a message with a glycin-related error
message.

Greetings
Marc

Control: retitle -1 "WARNING: Glycin running without sandbox" when AppArmor profile doesn't allow the sandbox to work
Control: affects -1 + libreoffice thunderbird evince papers

The common factor is that these apps have an AppArmor profile that
doesn't allow glycin's sandboxed image loaders to operate as designed:
one layer of security hardening is breaking another. There does not seem
to be any easy solution to this.

For thunderbird, this is <https://bugs.debian.org/1127710>. A mitigation
is that thunderbird's AppArmor profile is not (meant to be?) enabled by
default, so only users whose systems have it enabled (for whatever
reason) are affected. It seems that the most likely resolution to that
bug report will be to remove thunderbird's AppArmor profile (which is
probably not an effective security boundary in practice because it
already has to allow so much, in order to not break expected
functionality) which would result in gdk-pixbuf / glycin / bwrap working
as intended.

evince is another affected app (<https://bugs.debian.org/1127935>) and I
sent some prototype AppArmor profile changes to
https://salsa.debian.org/gnome-team/extras/evince/-/merge_requests/10,
but it really needs help from an AppArmor expert (which I am not) to
turn that prototype into something releaseable.

For the other affected apps such as libreoffice and papers, I think the
solution will have to involve either extending their AppArmor profiles
so that the sandboxed image loaders can work (if the AppArmor profile is
providing value), or removing/disabling the AppArmor profile (if it
isn't practically helpful to mitigate/prevent attacks and is only
causing us problems).

     smcv

Hi Simon,

It is. And it helped. Addidionally, setting GTK_USE_PORTAL=1 as the KDE
Launcher file does also seems to help here.

Greetings
Marc

Hi Simon,

It is. And it helped. Addidionally, setting GTK_USE_PORTAL=1 as the KDE
Launcher file does also seems to help here.

Greetings
Marc

Hi,

Simon McVittie (2026-02-22):

IIRC I've seen a comment somewhere in a discussion on an issue or PR
in the https://github.com/roddhjav/apparmor.d/ project that said it
was possible to force Glycin to turn off its sandboxing, by denying
1 of the access it was using on startup to check if sandboxing
was possible.

This is clearly a poor long-term choice, but if a 1-liner quick fix
implements this (bringing us back to where we were 2 weeks ago in
terms of security and bugs), it might buy us some time while we figure
out how we want to approach the whole thing.

I'll try to find this workaround tomorrow.

Cheers,

intrigeri (2026-02-24):

I could not figure out how to do that without evince 48.1-3 crashing
on startup, so I'm not confident in this temporary quick fix.

Cheers,

Dear all,

Is there any news on this?

I know that
sudo aa-disable /etc/apparmor.d/libreoffice-*

Would make the warning go away.
But is there any other way, It seems that the libreoffice profile needs to be updated to include glycin.

Thanks,
Carlos

be updated to include glycin.

There might be a Glycin abstraction missing in the AppArmor package which
could be called by the various profiles.

https://github.com/roddhjav/apparmor.d/issues/881 might have pointers.

Regards,

Hi,

Am 06.03.26 01:55, schrieb Carlos Silva:

I wonder why.

libreoffice-soffice(.bin) is in complain mode.

Interestingly, the (somehow implied?) glycin stuff added. And some of
those even gets into enforced automatically?

grep -E '(mode|libreoff)' gives me:

36 profiles are in enforce mode.
   libreoffice-senddoc
   libreoffice-soffice//gpg
   libreoffice-xpdfimport
28 profiles are in complain mode.
   libreoffice-oosplash
   libreoffice-soffice
   libreoffice-soffice//null-/usr/bin/bwrap
   libreoffice-soffice//null-/usr/libexec/glycin-loaders/2+/glycin-image-rs
   libreoffice-soffice//null-/usr/libexec/glycin-loaders/2+/glycin-svg
0 profiles are in prompt mode.
0 profiles are in kill mode.
76 profiles are in unconfined mode.
2 processes are in enforce mode.
6 processes are in complain mode.
   /usr/lib/libreoffice/program/oosplash (19996) libreoffice-oosplash
   /usr/lib/libreoffice/program/soffice.bin (20006) libreoffice-soffice
   /usr/libexec/glycin-loaders/2+/glycin-image-rs (19770) libreoffice-soffice//null-/usr/libexec/glycin-loaders/2+/glycin-image-rs
   /usr/libexec/glycin-loaders/2+/glycin-image-rs (19814) libreoffice-soffice//null-/usr/libexec/glycin-loaders/2+/glycin-image-rs
   /usr/libexec/glycin-loaders/2+/glycin-svg (19756) libreoffice-soffice//null-/usr/libexec/glycin-loaders/2+/glycin-svg
   /usr/libexec/glycin-loaders/2+/glycin-svg (19800) libreoffice-soffice//null-/usr/libexec/glycin-loaders/2+/glycin-svg
0 processes are in prompt mode.
0 processes are in kill mode.
0 processes are in mixed mode.

IMHO aa-disable is a bad idea for a warning.
There is a reason some profiles are kept in enforcing. Especially the gpg one...

See my other mail. Could do if there is some abstraction. I am not going
to chase down what needs to be done here in a profile.

Regards,

Rene

Hi,

Am 14.03.26 01:29, schrieb Yves-Alexis Perez:

That would be helpful, yes...

Regards,

Rene

I believe the profiles with "//null-" in their names are automatically
synthesized by complain mode: libreoffice doesn't have a rule allowing
it to run /usr/bin/bwrap or /usr/libexec/glycin-loaders/**, but the
absence of such a rule would prevent it from working, defeating the
purpose of complain mode, therefore AppArmor synthesizes a blank profile
in complain mode for them and behaves as though libreoffice's profile
allowed a transition to that new profile.

Sure, but libreoffice's profile isn't enforcing, so its only purpose is
to generate warnings, and it will never actually prevent anything. (This
is not necessarily a bad thing - I did the same for some games - but it
does limit its value.)

     smcv

Hi,

Am 15.03.26 um 12:35 schrieb Simon McVittie:

Hmm.

Interesting. Makes sense.

Some profiles are:

    libreoffice-senddoc
    libreoffice-soffice//gpg
    libreoffice-xpdfimport

Yeah, the value is limited for soffice(.bin)/oosplash itself, indeed.

Regards,

Rene

Hi,

I've tried to Cc all interested parties. Please consider trimming down
the list of Cc upon reply, thanks!

Thanks to the work by Aaron Rainbolt, the apparmor.d project, and
multiple other AppArmor contributors, we now have a way to allow an
AppArmor-confined app to use Glycin's bwrap-based sandboxing
mechanism. I understand the chosen approach has some drawbacks which
I don't full understand, but it does seem to work.

To do so, ensure the app's profile has this line:

    include if exists <abstractions/glycin>

On systems that lack this abstraction (e.g. Trixie or older
testing/sid), this will be a no-op.

On systems that do have this abstraction (i.e. apparmor >= 4.1.7-3
which I've just uploaded), this should fix the problem tracked in the
bug reports I've sending this email to. If it doesn't, please let
me know!

I intend to do that work upstream for torbrowser-launcher.
I can't commit to do it for other packages.

Thanks a lot for your patience,

Hi,

I'm taking the example of LibreOffice below, but other apps may
be in the same case. Note that I'm just an end user.

Thanks a lot for the work, but...
that uses Glycin, LibreOffice does *not* use Glycin directly, and
I suppose that it does not even know that Glycin will be used:
here, Glycin is used via the GDK Pixbuf library (a.k.a. gdk-pixbuf).
And perhaps gdk-pixbuf may no longer use Glycin in the future. So it
would be strange if the libreoffice package had to add this line.

So, how should the above line be added? Some kind of double
inclusion (the app's profile → gdk-pixbuf → abstractions/glycin)?
Or some automatic way for Glycin to add such a line to the profiles
of the apps via some kind of mechanism?

Hi,

Am 01.06.26 um 16:36 schrieb Vincent Lefevre:
Exactly.

I would not be opposed to it though if it made the "issue" disappear. But it's indeed not ideal.

Or it being in LibreOffices profile automatically makes it work even  though there's no usage except for using gdk-pixbuf?

No idea.


Regards,


Rene