Bugzilla

>As these processes use the same seccomp filter as any other app, they may be less secure than the native Sandbox

This shouldn't be an issue for us, seccomp filters nest and the most restrictive wins. (Maybe you weren't implying that, i.e. you're just explaining the issue with the non-official Chromium builds?)

The tl;dr is already in bug 1756236, in that our sandbox was designed to work even if the namespacing is blocked, whereas Chromium assumes it can always have a namespace (if necessary through the use of suid root binaries) and this assumption breaks in Flatpak. At least that's what used to be the issue there, I haven't looked at this code in Chromium for a while.

>I could not find any explanation, how the Flatpak version can be equally secure as the native versions, which have access to way more system calls.

This is false for the aforementioned reason, if anything the Flatpak version will have access to less system calls. (This has historically broken crash reporting until we fixed it, etc). It doesn't have a user namespace, but it does have the isolation from Flatpak itself instead.

>Firefox is widely assumed as less secure as Chromium. I personally prefer it a lot though, but the problems of security have to be seen, explained and taken care of for Firefox to regain its place.

Assumptions are always dangerous and can quickly lead to incorrect reasoning and conclusions 😉

>As these processes use the same seccomp filter as any other app, they may be less secure than the native Sandbox

This shouldn't be an issue for us, seccomp filters nest and the most restrictive wins. (Maybe you weren't implying that, i.e. you're just explaining the issue with the non-official Chromium builds?)

The tl;dr is already in bug 1756236, in that our sandbox was designed to work even if the namespacing is blocked, whereas Chromium assumes it can always have a namespace (if necessary through the use of suid root binaries) and this assumption breaks in Flatpak. At least that's what used to be the issue there, I haven't looked at this code in Chromium for a while.

>I could not find any explanation, how the Flatpak version can be equally secure as the native versions, which have access to way more system calls.

This is false for the aforementioned reason, if anything the Flatpak version will have access to less system calls. (This has historically broken crash reporting until we fixed it, etc). It doesn't have a user namespace, but it does have the isolation from Flatpak itself instead. I wouldn't want to make a statement whether that is better or worse.

>Firefox is widely assumed as less secure as Chromium. I personally prefer it a lot though, but the problems of security have to be seen, explained and taken care of for Firefox to regain its place.

Assumptions are always dangerous and can quickly lead to incorrect reasoning and conclusions 😉

>As these processes use the same seccomp filter as any other app, they may be less secure than the native Sandbox

This shouldn't be an issue for us, seccomp filters nest and the most restrictive wins. (Maybe you weren't implying that, i.e. you're just explaining the issue with the non-official Chromium builds?)

The tl;dr is already in bug 1756236, in that our sandbox was designed to work even if the namespacing is blocked, whereas Chromium assumes it can always have a namespace (if necessary through the use of suid root binaries) and this assumption breaks in Flatpak. At least that's what used to be the issue there, I haven't looked at this code in Chromium for a while.

>I could not find any explanation, how the Flatpak version can be equally secure as the native versions, which have access to way more system calls.

This is false for the aforementioned reason, if anything the Flatpak version will have access to less system calls. (This has historically broken crash reporting until we fixed it, etc). It doesn't have a user namespace, but it does have the isolation from Flatpak itself instead. I wouldn't want to make a statement whether that is better or worse (but having both would be better).

>Firefox is widely assumed as less secure as Chromium. I personally prefer it a lot though, but the problems of security have to be seen, explained and taken care of for Firefox to regain its place.

Assumptions are always dangerous and can quickly lead to incorrect reasoning and conclusions 😉

>As these processes use the same seccomp filter as any other app, they may be less secure than the native Sandbox

This shouldn't be an issue for us, seccomp filters nest and the most restrictive wins. (Maybe you weren't implying that, i.e. you're just explaining the issue with the non-official Chromium builds?)

The tl;dr is already in bug 1756236, in that our sandbox was designed to work even if the namespacing is blocked, whereas Chromium assumes it can always have a namespace (if necessary through the use of suid root binaries) and this assumption breaks in Flatpak. At least that's what used to be the issue there, I haven't looked at this code in Chromium for a while.

>I could not find any explanation, how the Flatpak version can be equally secure as the native versions, which have access to way more system calls.

This is false for the aforementioned reason, if anything the Flatpak version will have access to less system calls. (This has historically broken crash reporting until we fixed it, etc). It doesn't have a user namespace, but it does have the isolation from Flatpak itself instead. I wouldn't want to make a statement whether that is better or worse (but having both would be better if feasible).

>Firefox is widely assumed as less secure as Chromium. I personally prefer it a lot though, but the problems of security have to be seen, explained and taken care of for Firefox to regain its place.

Assumptions are always dangerous and can quickly lead to incorrect reasoning and conclusions 😉