Michael2852 It's possible to use bwrap directly (used internally by Flatpak) to sandbox a Chromium based browser without breaking process isolation, though it's hard to do and not enough information about this is available IMO. It will also depend on your distro's (kernel) user namespace configuration.
I did some tests and ran vanilla Chrome on Void Linux inside a bwrap sandbox while preserving process isolation, but I'm not an expert so I'm reluctant to share my script and give some other non-expert a false sense of security with it (I also did not restrict system calls with seccomp, which is also possible through bwrap and done by Flatpak).
Some pointers if you'd like to experiment with this -
- D-Bus access can be managed by xdg-dbus-proxy, though note that malicious programs will likely be able to access D-Bus in an unrestricted manner anyway if you share the network namespace used outside the sandbox with the sandbox (I need to do more research about this); D-Bus is required for desktop portals to work, though stuff like the document portal has even more largely undocumented requirements.
- A "secure" Wayland connection (see the security-context-v1 protocol) can be managed with way-secure.
In my experience implementing a sandbox for an application "from scratch" with bwrap is extremely difficult, and alternatives to it are either as difficult to use or, AFAICT, subpar in their implementation unfortunately.
Some interesting alternatives are minijail0 (used by Google in Android and ChromeOS, also usable as a command line program like bwrap) and crablock which is a fairly new project written in Rust which utilizes "bleeding edge" Linux security features.
With all that said, the best solution currently if you don't trust the browser itself is to use a VM IMO.