On 2026-02-24 21:08, Jeremy Bícha wrote:
Currently, the only things known to be broken are volumeicon and some
AppArmor profiles...
And this is the real issue. My system is GNOME free and it's not just because I
don't like GNOME (once, I really liked gnome2). It's simply because I can't
confine apps in apparmor profiles under such desktop environments like GNOME or
KDE -- it's simply impossible. That's why I don't use these highly integrated
desktop environments -- I really like security.
When I upgraded the libgdk-pixbuf-2.0-0 package (to the one with glycin), my
system just died after reboot... And I asked myself WTF? Then I found this
glycin change, and I googled it, and found out that it's a GNOME component. I
asked myself again -- WTF is GNOME doing on my machine? I checked APT for
packages related to GNOME, and I can't find anything. So this is the second
problem, which is that we're starting to have GNOME components in non-GNOME
environments -- it really sucks...
But let's focus on the very first problem. This whole glycin required me to add
many rules to many apparmor profiles -- my system currently have the following:
# aa-status | grep are
948 profiles are loaded.
774 profiles are in enforce mode.
104 profiles are in complain mode.
0 profiles are in prompt mode.
0 profiles are in kill mode.
70 profiles are in unconfined mode.
69 processes are in enforce mode.
11 processes are in complain mode.
0 processes are in prompt mode.
0 processes are in kill mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
So as you can see I utilize apparmor a lot. And I could update all the profiles
that need to be updated for the glycin change, but there's a problem. What
problem? Apps now need the following rules:
/usr/bin/bwrap rPx,
/usr/share/glycin-loaders/*/conf.d/ r,
/usr/share/glycin-loaders/*/conf.d/glycin-*.conf r,
/usr/libexec/glycin-loaders/*/glycin-* rix,
Not a big deal -- can be done. The problem is with this whole bwrap, which
requires bunch of CAPs like sys_admin or net_admin, here's the (not complete)
list:
network netlink raw,
allow userns create,
capability sys_admin,
capability sys_chroot,
capability setpcap,
capability sys_ptrace,
capability net_admin,
capability sys_resource,
mount,
umount,
pivot_root,
And still, not a big deal, because it's a sandbox mechanism -- it's normal. Just
create a child profile and execute this bwrap under this child profile. And this
switching between the main app profile and bwrap child profile gives
*no_new_privs* errors. You can of course avoid this no_new_privs errors by
directly executing bwrap inside of the main app profile. But this gives the app
the access to what bwrap needs, which includes everything listed above.
Including rules allowing for everything in all (or most of) apparmor profiles
defeats the purpose of having apparmor enabled... And this is the real problem.
I've seen similar scenario before when apparmor introduced *userns* feature per
app, but Debian has already forced its users to use apparmor by enabling it by
default. This created a problem with app starting because they didn't have a
apparmor profile allowing this userns. How this story ends? Apparmor is still
enabled by default "because of security", and we get more and more profiles,
which
are similar to this:
# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"
...
To hell with this kind of security....
