Chrome and Chromium should not run as unconfined processes, even in a flatpak?
The internet suggests that SELinux is applied within the flatpak. I’m not sure how to check that those labels are applied to processes within the flatpak?
/? selinux flatpak: Google Search ::
I’m afraid this does apply to the Chrome and Chromium (and Firefox) flatpaks, which also have their own applications sandbox: Flatpak - a security nightmare ::
Most of the apps have full access to the host system but users are misled to believe the apps are sandboxed
Steps to verify that the Chrome and Chromium and Firefox flatpaks are running unconfined
It says the security mailing list is archived? A security.txt could link to the current list.
I believe this is an issue with all rpm-ostree distros that e.g. install Firefox as a flatpak by default or discourage installing layered packages instead of flatpaks?
Create a new profile based on Firefox wayland. Maybe add pulseaudio permission (Firefox still has no native Pipewire output?), and a desktop entry is created
Sure, but the easiest way to run Firefox or Chromium in Bubblewrap (the sandboxing system that Bubblejail uses under the hood) is to install the Flatpaks, since Flatpak already sandboxes applications with Bubblewrap (in fact Bubblewrap was created by the Flatpak project for Flatpak)
I’m not convinced this is an issue, SELinux is only one of many ways of sandboxing or constraining an application, and Flatpak already implements another way (Bubblewrap), that’s one of the advantages of using Flatpak
docker and podman support --security-opt=seccomp=profile.json, but seccomp syscall filtering is not a replacement for container-selinux, gvisor runsc, firecracker, or kata-containers.
The container labeled container_t:s0:c1,c2 can access files labeled as container_file_t:s0:c1 and container_file_t:s0:c2 because categories {c1} and {c2} are subsets of set {c1,c2} but it cannot access container_file_t:s0:c3 because category {c3} is not subset of set {c1,c2}. A similar concept also applies to container_t:s0:c2,c3. When an object does not have any category (container_file_t:s0) an empty set is also part of every process set, which means every container with whatever category can access it.
Fair enough, although the original discussion didn’t specify sandboxing between tabs (single site/security zone is a perfectly valid use case for a sandboxed browser), and as you say Chromium would work perfectly fine so it’s still a valid option for OP as long as they either bear in mind the limitations of Firefox or just use a Chromium based browser in a Flatpak
Using browsers as Flatpak will result in a weakened sandboxing structure, because it can’t use namespaces and chroots to the same extend for sandboxing and site isolation, as it would with a native install due to Flatpak’s seccomp filter.
This applies to Chromium- and FF-based browsers. You can check the resulting namespace structure with lsns to see the difference between Flatpak and non-Flatpak version. FF even completely drops namespaces and chroots within its Flatpak version, while Flatpaks of some Chromium-browser use patches to get a weakened replacement of Chromium’s native namespace structure.
I would recommend against unnecessarily weakening your browser’s sophisticated multi-process sandboxing structure, thus recommend against using a Flatpak version. Browsers are one of the most security critical parts on end-user devices these days.
While you can use Selinux to confine Flatpaks, be aware that Selinux is not namespaced, so there are some limitations. Also it will either give the Flatpak access to user_home_t rendering the additional confinement ineffective or it will provide user friction, because users would need to relabel files. While it could be an improvement, it would not be able to fully replace the weakened sandboxing structure of Flatpak browser and especially not the weakened site isolation.
If you want a more secure browser, don’t unnecessarily weaken the browser’s defenses, don’t use the Flatpak version. Disable JIT, which will significantly reduce the number of renderer RCEs. Even though it is badness enumeration you could use a DNS which blocks known malicious domains and an ad blocker preferably built into the networking stack, like Brave does. These are low-friction efficient measures and easier to use and maintain than Selinux-policies.
Additionally you could limit access to media and JS, which would have more user friction, but also make quite a lot more secure. Or even put it inside a VM to mitigate weaknesses of the kernel.