Recent Glycin sandboxing vs. unprivileged user namespaces

flooklab · 2025-10-26 01:45:57

After my newest upgrade I noticed the session logs are being cluttered with a lot of these lines:

WARNING: Glycin running without sandbox.

I realized that this is obviously due to bubblewrap failing because I had disabled unprivileged user namespaces in sysctl by:

kernel.unprivileged_userns_clone=0

Setting this to 1 indeed stops those warnings.

As I never really used bubblewrap before, that was never a problem anyway. But now that so many packages pull in the Glycin sandboxing through the gdk-pixbuf2 dependency I will have to either enable unprivileged user namespaces again or install the bubblewrap-suid package instead (I am not going to adopt the "-noglycin" stuff from AUR for the moment). As far as I understand, however, there are some security concerns against both solutions (namespaces and setuid). I actually recalled this thread https://bbs.archlinux.org/viewtopic.php?id=254868 on the same consideration but it looks like there was no definitive answer at the end.

I guess if there is no particular other need to have the user namespaces enabled I should prefer to just stick to the setuid variant.
But, honestly, I don't really know what I'm talking about here. So, what do you think is the most sane/secure solution? Or should I not worry that much at all?

seth · 2025-10-26 09:56:16

https://gitlab.gnome.org/GNOME/glycin/- … 071ee20e78
https://gitlab.gnome.org/GNOME/glycin/-/issues/203

Probably file a bug to at least cut down on the logging, but upstream seems to be dead-set on the beyond-idiotic idea to rip the system wide open in order to facilitate the isolated protection of a single attack vector (ignoring others in the realm because the securely read payload can still exploit bugs in the actual client) despite this now also being perfectly circumventable, since we had to break any securing of the parenting process itfp.

There's no sane solution to this.

progandy · 2025-10-26 11:42:49

seth wrote:

https://gitlab.gnome.org/GNOME/glycin/- … 071ee20e78
https://gitlab.gnome.org/GNOME/glycin/-/issues/203
Probably file a bug to at least cut down on the logging, but upstream seems to be dead-set on the beyond-idiotic idea to rip the system wide open in order to facilitate the isolated protection of a single attack vector (ignoring others in the realm because the securely read payload can still exploit bugs in the actual client) despite this now also being perfectly circumventable, since we had to break any securing of the parenting process itfp.
There's no sane solution to this.

Reading the issue it seems you'd have to replicate the stuff bwrap is used for here with landlock/seccomp and wrap in in a "simple" library that glycin can depend on and feel as if the burden of the sandboxis not placed on the glycin maintainers
And preferably the library has to be endorsed by a larger organisation like gnome so it is accepated as "secure sandbox"...

Last edited by progandy (2025-10-26 11:44:07)

flooklab · 2025-10-26 15:19:44

seth wrote:

There's no sane solution to this.

Ok, I see...

But apart from this specific Glycin context:
If I wanted to use Bubblewrap myself (for whatever), does anybody think that one of

Regular bubblewrap + unprivileged user namespaces enabled
Setuid bubblewrap + unprivileged user namespaces disabled

could be a generally more safe or risky setup (say in terms of probability/amount of attack surface introduced by usage of setuid)?
It's probably hard to tell in general, but someone here probably knows more about it.

seth · 2025-10-26 15:42:32

Edit: the below was meant as response to @progandy's post, F5…
---------------------
On top of that you've stuff like https://github.com/containers/bubblewra … 1892840830 that will systematically break bubblewrap specifically - by using systemd…

you'd have to replicate the stuff bwrap is used for here with landlock/seccomp and wrap in in a "simple" library

One of the more important things I learned about in life is https://en.wikipedia.org/wiki/Deferent_and_epicycle - sometimes it's necessary to step back and question wtf one's doing here itfp.
"Security" is not hanging a padlock onto a random door and hardening things isn't a virtue in and by itself (I'll spare you the obvious pun)

The present approach seeks to insulate the image loader from the main process, assuming malicious input (image file) could exploit bugs in the loader and severely infect the loading process that therefore must be closely locked down.
Fine.

Now, if I have a trusted client that only loads the same images from /usr/share/icons as every other client, do I really need to harden that task itfp?
At all?

Assuming the (what percentage of?) cases were a trusted client indeed deals with questionable input and completely ignoring that the payload itself could be a problem (notably color profiles, exif and other metadata):
What you then want is an external context that might get exploited and therefore sufficiently locked down.
But it certainly does not have to be a (gazillion of) child process(es).

It needs to accept requests and output filtered/sanitized results and be sufficiently constrained for random input not being able to leverage an exploit into an attack.
But the I/O can be any kind of IPC (a child process is just a very specific form of that anyway) - socket of file based.
The service (let's call it a daemon) and protocol need to be sufficiently robust against failures (crashes, locks - ie. you want asynchronous action, job id's, frequent re-requests and timeout kills and trigger-based execution)
Ifff communication/payload integrity is a concern, also encryption and signatures (mind you that I've not seen anything like this in the ubiquitous dbus communication throwing around passwords etc. - but hey…)

This allows arbitrary constraint of the client process (insulating it from the system) as well as the image reading service (insulating it from other parts of the system) - whether to allow an untrusted client to load icons from files w/o having actual access to the filesystem or to keep a trusted client away from untrusted input.

Demanding untrusted clients to be afforded the capabilities to spawn new bwrap processes that will then pot. just end up tunneling malicious payload through the secured reader is completely bonkers.

* It doesn't guarantee "the security" - because that's not a thing (apparently LLMs are now attacked by exploiting scaling artifacts to inject prompts), but
* It systematically weakens the overall system, to the point where
* It will allow malicious clients to skip the "enforced" security measure entirely

And yes, I'm aware that I'm probably effectively talking pixbuf into depending on dbus

Last edited by seth (2025-10-26 16:34:16)

seth · 2025-10-26 16:43:53

Sorry, I skipped your response:

It's probably hard to tell in general, but someone here probably knows more about it.

Next to eschwartz, the warning in https://wiki.archlinux.org/title/Securi … plications and https://bugs.archlinux.org/task/63295.html w/

The correct solution for the hardened kernel is to be able to run bubblewrap as a hardened application, which is now available via bubblewrap-suid.

and https://bugs.archlinux.org/task/36969 aside, I'd opt for bwrap-suid
You can still mount nosuid and remove that flag w/ a bind-mount for specific binaries but kernel.unprivileged_userns_clone=1 is all or nothing and "all" gets you into https://gitlab.com/apparmor/apparmor/-/ … estriction that details the various problems w/ that.

Arch Linux

#1 2025-10-26 01:45:57

Recent Glycin sandboxing vs. unprivileged user namespaces

#2 2025-10-26 09:56:16

Re: Recent Glycin sandboxing vs. unprivileged user namespaces

#3 2025-10-26 11:42:49

Re: Recent Glycin sandboxing vs. unprivileged user namespaces

#4 2025-10-26 15:19:44

Re: Recent Glycin sandboxing vs. unprivileged user namespaces

#5 2025-10-26 15:42:32

Re: Recent Glycin sandboxing vs. unprivileged user namespaces

#6 2025-10-26 16:43:53

Re: Recent Glycin sandboxing vs. unprivileged user namespaces

Board footer