I mean sandboxes are just pretty complex. Chromium relies on user namespaces for process isolation. Flatpak browsers are isolated but have no internal isolation of processes (one tab could attack another tab). At the same time the Flatpak sandbox itself relies on user namespaces, while the flatpakked browser cannot use the namespaces internally.
Then there is the hardened kernel which disables user namespaces for security reasons, on the other hand people say running the Sandbox as suid means if there is a vulnerability processes get root access.
Flatpak browsers put less trust in the code, but more in the maintainer that has to keep them as updated as possible.
Just so you know, Chromium Browsers are more secure if you use the native package. But just for privacy reasons I would not run Chrome unrestricted in my system.
Thanks! Yes its a shame that Debian (and Leap?) Will not have Plasma6 in like 6 months where stable release would fit perfectly.
My experience is the same, on Manjaro Plasma was way better than on Kubuntu and Manjaro convinced me of Plasma. Fedora is a sweet spot and staying with F39 for a while (even though I will probably switch to F40 right away as Plasma6 has sooo many bug fixes I personally reported) could work.
You mean a rootful Distrobox with a DE in it? I have to try that out, sounds crazy. Would need a seperate home if that is possible, as I dont want to have messed up dotfiles.
They will work on ungoogled chromium too though, I guess.
In theory there is even the ability to store a chrome:flags override and use it like a user.js. So you could use upstream chromium and not rely on outdated stuff.
Flatpaks are more and less secure. Their Sandbox improves 99% of apps security as other sandboxes are hard to setup and thus nearly nonexistent.
Browsers have their own, so just dont use Flatpaks there.
I am not sure about microcode, but processes running as root are maybe more critical, but it sounds like any process could have exploits if microcode is a problem. Also, RiscV or even ARM will be waaay better here, as their instruction set is not dozens of years old and extremely bloated.
As we get our apps from secure repos, with projects keeping track of every Git commit etc, we just had no malware really.
The only problem is that Flatpaks, like appimages, “just work” and dont have to evolve like the rest of the OS will. Their main goal is to work everywhere, and Devs always choose convenience over security.
For example Portals are not implemented in most old big projects like Libreoffice, Gimp, Inkscape etc. Scribus is even X11 only. But developers will not remove the filesystem=host permission and replace it with “just all the media locations”. This will still be a problem, but at least apps could not read Kernel logs etc anymore.
Also as they “just work” its easy to abandon them and dont update. The “outdated Runtime” Warning is a veeery good indicator of a project using old and probably insecure libraries. But afaik there is no automatic CVE patching in flatpak-builder which is a huge problem.
Even though pretty old and probably outdated, some points are for sure true. Some apps like Onionshare are horribly outdated, and unless every app has at least one packager responsible for it, best official and paid, its a total mess.
These where not the sources I refer to, and it is pretty complex. Secureblue disables user namespaces and uses bubblewrap-suid for security, but after madaidans statement that would mean a hole in bubblewrap allows the app root privileges.
No shit I believe FOSS projects investing in PR and corporate Design like that are on a very good path. Things need to look shiny today, KDE & Opensuse icons, wallpaper contests, this is so nontechnical but attrackts lots of attention.
I imagine if Darling gets as well supported it would be better. But it will not be optimized as much, even though the core architecture may be way more similar