>most parts of internal sandboxing are disabled Hmm? You lose the namespace isolation, and by extension the chroot, but that's it. It's definitely nice to have, but to say it's "most" of the sandboxing seems a misrepresentation. Note that some distros disable the kernel support for them by default, so that's what they currently get regardless of Flatpak. Maybe there's confusion here because Chrome assumes it can always have either namespaces or a setuid root helper if it wants a sandbox, but Firefox is designed to still have sandboxing without the latter - we don't want to ship setuid binaries. >internal sandbox isn't effective due to lack of direct User Namespaces access Are you aware of some EoP or sandbox bypass that's made possible by the lack of user namespaces currently? From our perspective it's defense in depth, not a required component.
Bug 1756236 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
>most parts of internal sandboxing are disabled Hmm? You lose the namespace isolation, and by extension the chroot, but that's it. It's definitely nice to have, but to say it's "most" of the sandboxing seems a misrepresentation. Note that some distros disable the kernel support for them by default, so that's what they currently get regardless of Flatpak. Maybe there's confusion here because Chrome assumes it can always have either namespaces or a setuid root helper if it wants a sandbox, but Firefox is designed to still have sandboxing without the latter - we don't want to ship setuid binaries. >internal sandbox isn't effective due to lack of direct User Namespaces access Are you aware of some EoP or sandbox bypass that's made possible by the lack of user namespaces currently? From our perspective it's (additional) defense in depth, not a required component to have sandboxing.