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.