QTWEBENGINE_DISABLE_SANDBOX=1 may be needed to run Qt applications that use QtWebEngine under Firejail.
At least this is the case for https://appimage.github.io/Galacteek/.
Would it make sense to have Firejail set this environment variable globally? I see it already exists in the source code but is commented out.
Currently this is only set for Viber,
Also see here.
Is it already known under which circumstances QtWebEngine needs this option?
I would say it should be never added. Firejail sandbox should be tweaked instead.
Listing here which applications needs this:
Is it already known under which circumstances QtWebEngine needs this option?
Always (given that unprivileged user namespaces are enabled).
It's all about the chroot syscall being included in the default seccomp filter. As this is an increasingly common problem, would it justify a new option?
It would be best if it would not need a special option to be invoked by the user. (If the user has to do something, then QTWEBENGINE_DISABLE_SANDBOX=1 is fine imho.)
It's all about the chroot syscall being included in the default seccomp filter. As this is an increasingly common problem, would it justify a new option?
Maybe tweak seccomp rule to allow defining firejail defaults +/- a chosen syscall,
like seccomp +chroot?
I think we schould implement @Vincent43 idea
How future proceed here?
Adding this to Viber.profile and removing env QTWEBENGINE_DISABLE_SANDBOX=1 from there should be enough to close this. You may include this in https://github.com/netblue30/firejail/pull/2927 and wait till https://github.com/netblue30/firejail/pull/2926 is merged.
Well, I'd say this ticket can be closed once we the user won't need to manually run env QTWEBENGINE_DISABLE_SANDBOX=1 anywhere anymore, not just for Viber.
@probonopd you mean appimage apps? They seem to use default.profile. The only fix I see is to remove chroot from default seccomp filter.
Yes, I mean AppImage apps. What would the security implications be of what you are suggesting? Would the FIrejail sandboxing still be effective?
If we have to disable either FIrejail's or Chrome's sandbox, then I'd say enable Firejail's and disable Chrome's, e.g., by exporting QTWEBENGINE_DISABLE_SANDBOX=1 all the time.
We just need to allow one additional syscall (chroot) which many apps use for self-sandboxing. Everything else will stay intact and app will be protected by both firejail and chrome sandboxing.
Thank you very much.
@Vincent43 Maybe rather than removing chroot from the default seccomp blacklist, we could just remove it from default.profile? (or I understood you wrong and that was what you were saying)
@smitsohu chroot breaks most electron apps and will ultimately break all of them once they update to latest version. It's no longer suitable default in apps world.
Most helpful comment
Maybe tweak
seccomprule to allow defining firejail defaults +/- a chosen syscall,like
seccomp +chroot?