Is it better to have a browser sand-boxed with Flatpak or not?

Thx

Too late

Why he license his stuff under MS-PL (Microsoft Public License)?

Why should I trust him?

3 Likes

What do you mean? It’s a person saying things confidently on the internet! It’s not possible for them to be wrong :wink: /hj

5 Likes

What’s wrong with MS-PL?

Dude it’s not a code to care about license

It’s just a guide it doesn’t matter which license used

The link list soirces in the hyperlinks, including an article by a whonix developer and security researcher criticizing firefox

Sources aren’t here for no reason

Would you like to go back to the times, where every small vulnerability in the browser let to taking over the whole user account or would you rather have exploit mitigations and sandboxing make it much more difficult for attackers?

Won’t save all your data within the user. For most home users this is the most important part of their system.

Browsers run as unconfined_t by default on Fedora. So Selinux won’t save you.

Not true for all browsers.

$ ls -Z /opt/google/chrome/
                system_u:object_r:bin_t:s0 chrome
                system_u:object_r:bin_t:s0 chrome_100_percent.pak
                system_u:object_r:bin_t:s0 chrome_200_percent.pak
                system_u:object_r:bin_t:s0 chrome_crashpad_handler
                system_u:object_r:bin_t:s0 chrome-management-service
system_u:object_r:chrome_sandbox_exec_t:s0 chrome-sandbox
                system_u:object_r:bin_t:s0 CHROME_VERSION_EXTRA
                system_u:object_r:bin_t:s0 default-app-block
                system_u:object_r:bin_t:s0 default_apps
                system_u:object_r:bin_t:s0 google-chrome

What about the process rather than the files?

ps -AZ | grep chrome

What do you intend to proof with your ls output? Check the process labels instead.

Strange that the process runs that way when the launching app is not totally unconfined.

All the experts from Secureblue (Hardened Linux) agree on this (Flatpak on browsers is bad!):

Just going to toss some technical info, since the answer is already there. Browsers in flatpak are significantly worse than non-flatpak.
Chromium based browsers, and electron apps, need to use Zypak or patches. Neither of which live up to native’s security. Notably because you either lose out on user namespaces or seccomp filtering, both parts are essential to chromium’s strong sandboxing. And you can’t use flatpak-spawn with seccomp due to how the spawning model works, and flatpak-spawn is how user namespace sandboxing is accessible in flatpak, since direct access to user namaspaces is blocked. A common argument is that sandboxing the whole browser is better, it isnt. Since you weaken the site sandbox (the riskiest part) and leveling it to the browser process sandbox (the most privilged part). So you make it slightly harder for your browser to exploit your system, you make it way way way easier for a site to exploit your browser.
This is even worse in firefox which disables entire portions of the sandbox and acts lile nothing is wrong. Doesnt try to account for them or anything, no Zypak equivalent or warning message, just worse sandboxing for little to no benefit.

2 Likes

I’m not trying to insult Secureblue contributors (It’s a cool and great project!), however without showing any proof of their formal education wrt to security, calling them “experts“ just isn’t honest.

Also, if you can, can you share some actual research on effectiveness of Chromium and Firefox sandbox under flatpak? Because right now it’s impossible to reply to your comment without repeating what was already said.

3 Likes

chromium devs decided to not support it for similar reasons

Chrome is the only package of Chromium that is officially supported. And Chrome have no business in caring about FDO Linux.

I’m torn between using RPM Firefox and having a supposedly safer browser, but with some friction on updates (including security updates), and using flathub’s firefox, which has supposedly worse sandbox, but way faster updates… and not having an official statement from Mozilla or a dedicated security research team from either Mozilla or the Firefox RPM packagers on Fedora is not helping this decision…

I’d rather the OS and software enforce minimal defaults and leave the security where it needs to be :stuck_out_tongue:

I’ve seen no problems of little-or-no sandboxing and running Firefox under admin accounts probably since 2016. It feels like the extra protection is for less-disciplined browsing habits.


The speed concern is real though: I was on F43 Workstation for a few hours and noticed app launches (including Firefox) being slower than FreeBSD; I got a performance baseline on another OS that Fedora seemingly can’t meet, and I didn’t even involve Flatpak or additional sandboxing/abstraction.

Officially supported only as a native, if that’s what you mean

“didn’t happen“ does not mean it won’t

Some damage are also silent, they can snoop and keep it for themselves, all without footsteps, even if they won’t use it it would still feel creepy

Sandboxing and non-root doesn’t offer 100% protection either :stuck_out_tongue: (malware can still occur with enough exploits; there’s enough complexity around for most people to not be watching too-deeply)

I wipe the OS between OS versions and check stuff frequently: My browsing habits avoid everything suspicious already seemingly, but if anything made it to the OS I’d see it with random file and network/hardware resource checking. Theoretic worst-case, malware might survive until an OS reinstall within a 6 month period (I do it practically weekly though :stuck_out_tongue:)