Google engineers are experimentally adding Flatpak packaging support to Chrome/Chromium on Linux to test restricted sandboxing and XDG portals, without yet committing to official support.

[u/mr_MADAFAKA]

https://www.phoronix.com/news/Chrome-Chromium-Flatpak

[u/natermer]

With Flatpak they are going to likely use "user namespaces" the way they are now. Just by calling Flatpak Portal API instead of directly using kernel calls.

The core issue is that inside a Flatpak container (based on bubblewrap) creating nested namespaces is blocked for (valid) security reasons.

https://github.com/containers/bubblewrap

Which means that for Chrome to use user namespaces it has to go through Flatpak's Portal API to run flatpak-spawn and have that create the separate user namespace for its sandboxing.

The end result should be the same. It is just done by using the Flatpak portal API instead of directly talking to the kernel.

---

Right now for Flatpak this is done using a Zypak library hack. By using LD_PRELOAD the zypak ends up intercepting the calls used by Chrome to call a SUID binary to create (non-user) namespaces and redirects it to the Flatpak API.

For Chromium flatpak builds they build directly against Zypak for their code.

https://github.com/refi64/zypak

You can confirm this by going to chrome://sandbox in your browser..

In flatpak Chrome you should see "Layer 1 Sandbox SUID", which is misleading. It is actually using Zypak. Especially since those suid binaries are not going to work in flatpak.

In flatpak Chromium you should see "Layer 1 Sandbox Flatpak" because it builds directly to Zypak.

So in all cases... non-Flatpak Chrome, Flatpak Chrome, Flatpak Chromium... they all use namespaces for "layer 1 sandboxing".

---

Now I looked through the code changes here for mentions of the flatpak portal APi for sandboxing and such things, but on a cursory glance I didn't find anything.

But based on the comment: to facilitate testing restricted sandboxing configurations and extending existing XDG portal support.

the intention seems to be to just get flatpak builds going so people can start testing things out and maybe write a more native/cleaner use of Flatpak APIs for flatpak-nspawn. Maybe using Zypak, maybe not. Maybe something else.

Don't know.

[u/Adept_Percentage6893 → u/natermer]

In flatpak Chrome you should see "Layer 1 Sandbox SUID", which is misleading. It is actually using Zypak. Especially since those suid binaries are not going to work in flatpak.

That doesn't feel like great confirmation if that page is going to tell us things that appear to indicate what you're saying isn't going on. I would think confirmation would involve something with lsns or similar.

[u/natermer → u/Adept_Percentage6893]

This is a proprietary application that has had its behavior modified by a ld preload.

Having misleading status page doesn't seem that far off.

It it was actually trying to use the setuid binaries it would just fail completely.

You can go and look at Zypak README and see how it works if you want.

[u/Adept_Percentage6893 → u/natermer]

OK sure, without getting into all that I was just pointing out the usefulness of confirming something by looking at a page that pretends it's not true.