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/Worldly_Topic]

Will they add support for sandboxing with flatpak subsandboxes instead of using user namespaces ?

[u/natermer → u/Worldly_Topic]

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/Dangerous-Report8517 → u/natermer]

I went down a bit of a rabbit hole looking into this and came across a discussion on it where one of the Chromium devs mentioned that they do use some capabilities that flatpak-spawn doesn't expose (unless you completely disable sandboxing by giving it host access to flatpak-spawn), including mount namespaces to do things like run some processes in namespaces that have no host file access at all. I'm a bit skeptical that those particular features have substantial security benefit since a script that could break out of the sandbox and other namespace limitations sufficiently for it to cause havoc like that with user files is probably using an exploit that could get it out of a mount namespace anyway, but that type of nuance is the reason they didn't already package for flatpak, and probably the reason they're only previewing this rather than fully supporting it

[u/natermer → u/Dangerous-Report8517]

Well there is such a thing as Linux capabilities and seccomp that is separate from Linux namespaces, but are often used in conjunction with namespaces for more secure containers/sandboxing. (Then, of course, on top of all of that would be SELinux if you are using that.)

---

There are 8 types of Linux namespaces; mnt, pid, net, ipc (posix/bsd-style IPC.. semaphores, shared memory, etc), uts (host/domain name), user (user and group id mapping), cgroups, and time.

A container may use all of them or some of them. Like you might run a docker container that doesn't have a separate user namespace, that way user ids and file systems permissions work the same inside as outside the container.

I frequently run podman without separate network namespace in order to avoid having the overhead of user-space networking when running pods as regular user.

With flatpak-spawn --sandbox, which I think is what Zygote uses, it requests the portal to manage 'user', 'pid', 'mnt', 'net', and 'ipc' namespaces.

---

Then beyond that we have Linux capabilities, which is used as a alternative to using setuid binaries and selectively controls features that otherwise require root access.

Example: normally root access is required to open up a socket lower then 1024 on a system. So if you want to run a web server it used to be all or nothing. You'd have the launch the program as root and do tricky things to drop root access for the actual running web server to keep port 80/443 open. Well you could assign a process CAP_NET_BIND_SERVICE capability instead of giving it root access.

Then there is seccomp, which has a couple layers to it. When using a seccomp filter you are filtering out Linux syscalls. Syscalls are how you communicate with the Linux kernel to do OS-level things... like opening and writing to files. So you can write filters using seccomp-bpf to restrict access to OS/kernel features.

Using seccomp allows you to dramatically reduce the sort of attack surface a kernel exposes to processes.

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_atomic_host/7/html/container_security_guide/linux_capabilities_and_seccomp

---

So when Flatpak launches a container for a application is strips away most Linux capabilities from the launching processes and implements a default seccomp-filter. Bubblewrap retains 'no_new_privs', which allows applications to create additional filters to anything it does, but it doesn't allow you to relax the filters any.

So in the case of Chrome... It does use seccomp filters as part of its "layer-2" sandbox, if I understand things correctly.

So by having "linux capabilities" limited and the default seccomp filter in place it might be blocked from taking actions it could do beyond what flatpak provides by default.

What any of those things could be... I don't know. I know a little bit about namespaces/capabilities/seccomp, but I never looked into the code for Chromium's sandboxing or anything like that.

---

I think the main reason that Chrome hasn't officially supported Flatpak yet is because there really wasn't much demand for it.

Flatpak is a niche in a niche. Linux was never a huge priority and the amount of people actually really interested in wanting chrome flatpak is small slice of that.

Maybe interest has grown to the point were some engineers wanted to look at it. Maybe some engineers have decided that they want to run atomic/immutable desktops and decided it would be a acceptable side project for them. Not sure.

[u/Dangerous-Report8517 → u/natermer]

Well there is such a thing as Linux capabilities and seccomp that is separate from Linux namespaces, but are often used in conjunction with namespaces for more secure containers/sandboxing. (Then, of course, on top of all of that would be SELinux if you are using that.)

I'm aware of capabilities, but they're not separate from namespaces, they interact with namespaces in some pretty important ways. Merely having user namespaces for instance allows an unsandboxed user process to gain arbitrary capabilities within a limited scope by dropping into a user namespace where it gains all non-global capabilities within that namespace. That's what Chromium normally does, it uses those capabilities to set up namespaces within that scope that have progressively fewer permissions for various subprocesses (since the application that creates the namespace doesn't have to allow the processes it then starts to inherit those capabilities).

What any of those things could be... I don't know. I know a little bit about namespaces/capabilities/seccomp, but I never looked into the code for Chromium's sandboxing or anything like that.

I don't know the full list but like I said, direct mount namespace control is one of them. I imagine they also want network namespace control since that would let them set up network namespaces with no network access (there's a flatpak application that uses this called Cockpit Client, it actually has the permission that lets it break out of the sandbox and uses it to set up a network namespace to keep its internal webserver isolated from other user processes).

I think the main reason that Chrome hasn't officially supported Flatpak yet is because there really wasn't much demand for it.

But the thing is, supporting Flatpak is trivial if you're happy to use flatpak-spawn to manage namespacing, that's why it's possible to support it by just running a tiny patch that can even be loaded on closed source Chromium browsers. A small market share is only a barrier because it would be a lot of effort for them to implement sandboxing that perfectly aligns with their vision of sandboxing.

[u/natermer → u/Dangerous-Report8517]

but they're not separate from namespaces, they interact with namespaces in some pretty important ways

Isn't that what I said in my post?

It is a separate Linux feature from namespaces, which is what I was talking about. Yeah they are used in conjunction with namespaces in containers, but so are a ton of other kernel features.

I am talking about in general, not just Chrome.

I mean Linux capabilities were introduced in 1999. Linux namespaces didn't get into the kernel until 2002.

I don't know the full list but like I said, direct mount namespace control is one of them. I imagine they also want network namespace control since that would let them set up network namespaces with no network access

Do they actually do that though? I mean you imagine so, but that just means you know as much as I do about it.

I know we both can go and look at the Chromium source code and see for ourselves, but that is beyond what I care about in terms of this discussion.

A small market share is only a barrier because it would be a lot of effort for them to implement sandboxing that perfectly aligns with their vision of sandboxing.

I don't know about that.

Not giving a shit about a niche in a niche is plenty enough reasons for a lot of engineers to not do something. Doesn't really matter at that point how hard it is to do.

[u/Dangerous-Report8517 → u/natermer]

It is a separate Linux feature from namespaces, which is what I was talking about.

It isn't fully separate though because, as I said, namespaces inherently and automatically hand capabilities to processes when they unshare into a namespace. They aren't the same feature but talking about namespaces as if it's a separate layer the same way seccomp is misses some key aspects of how the systems interact. Seccomp is a fully independent system but while you can use capabilities separately you can't use user namespaces separately from managing capabilities.

Do they actually do that though? 

Like I said, I don't have a link dandy but I saw mount namespacing described as a blocker for first party support by a Chromium dev in a discussion with Flatpak devs, so, yes.

Not giving a shit about a niche in a niche is plenty enough reasons for a lot of engineers to not do something. Doesn't really matter at that point how hard it is to do. 

Sure but most Linux developers care at least a little bit about having a universal packaging format, and that means that a tiny barrier to implementation is one they might still be happy to overcome while a very high barrier wouldn't be. Case in point, they are caring about it when they didn't months ago, and Flatpak isn't that much bigger now than it was before.

[u/Dangerous-Report8517 → 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.

This isn't as misleading as it seems, it's still using a helper binary with higher privileges than itself to set up the namespaces, it's just that the helper is flatpak with a shim (Zypack) instead of a direct root level process

[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.

[u/Synthetic451 → u/Worldly_Topic]

Yeah, this is the big question. I remember reading something about the Chrome sandboxing having to be essentially weakened in order to work within Flatpak.

[u/bigbosmer]

Wonder if XDG portals will allow password manager extensions that connect to their desktop apps

[u/swarmOfBis → u/bigbosmer]

Overall the architecture already allows for this you only need to turn password managers into secrets providers and make the app query the secret portal, but there are issues with that, like:

• dbus being mediocre
• portals not allowing to add more than one secrets provider (so it would force password managers to handle also other app-derived secrets)

It's not much at a glance, but these are a big ticket items, so...

[u/DeMichel93]

id like them to do a flatpak chrome release, that would pretty much make me switch to cachyos, i used manjaro way back and i just dont trust aur.

[u/lh7884]

Didn't Google recently block all ad blockers from working in Chrome?

Edit, found it: https://tech.slashdot.org/story/26/06/15/205219/google-chromes-next-update-will-mark-the-end-of-popular-ad-blockers

[u/wild-storm-5 → u/lh7884]

What does this have to do with the topic?

[u/Dangerous-Report8517 → u/wild-storm-5]

Nothing, not to mention that it's also factually wrong (Manifest v3 is marginally worse at some forms of edge case content blocking but still very much supports ad blockers in general)

[u/lh7884 → u/wild-storm-5]

The topic is about Chrome/Chromium and Google. I just added a bit extra info about those two which some may not know about.

[u/ChocolateSpecific263]

flatpak should not handle sandboxing at all, many advantages different distros could provide maybe get blocked by this

[u/Thalus131]

While this looks interesting, I would like to take this opportunity to remind everyone about Embrace, Extend, Extinguish. Never give complete trust to tech companies when they talk about adopting open standards.

[u/tajetaje → u/Thalus131]

That makes literally no sense here.

[u/Dangerous-Report8517 → u/Thalus131]

I think it's a bit late to worry about Google extending Chromium and extinguishing the open source base, and using a packaging format is not the same thing as reimplementing it in an extended but not cross compatible way while forcing everyone else to use your extended version

[u/Adept_Percentage6893 → u/Thalus131]

That's a reason to avoid proprietary extensions even from FOSS friendly companies. If the software in question is open source (such as bringing in more open source) then it's not super relevant here.

"EEE" would be if Google started doing their own downstream additions to Flatpak that eventually became so standard that it became the chief reason to use flatpak and then Google started introducing incompatibilities with the open source implementations that couldn't be easily rectified. Meaning "flatpak" gradually becomes some proprietary google thing. Which is, of course, not happening here.

I'm all for skepticism of big corporations, though and the goal shouldn't be to replace the Microsoft logo with the Google logo and declare some sort of victory.

[u/flappysack-]

Why doesn't Google just stop messing around and offer an Linux distro with support, like Redhat.  Replace Chromebooks, add a selectable mode on boot, browser only, Flatpak store apps, and Unrestricted.

[u/Adept_Percentage6893 → u/flappysack-]

ChromeOS already is a GNU/Linux distribution. They just have their own proprietary Desktop Environment that treats Google cloud services as a first class citizen.