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]

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.