docs: add article about flatpak browsers#354
Open
Commenter25 wants to merge 11 commits into
Open
Conversation
Up to standards ✅🟢 Issues
|
the intent is for this section to give an understanding of the problem, without needing to know the why. "introduction" implies too much that you're expected to follow into the next section
RKNF404
reviewed
May 3, 2026
|
|
||
| While we generally encourage Flatpak usage, this is *not* the case for web browsers. Currently, they are incapable of reaching the same level of security within the Flatpak sandbox. This [could change in the future](https://github.com/flatpak/flatpak/pull/6386), but right now, there are a lot of reasons to be concerned. As such, we consider it safest to avoid them entirely, and we encourage using other methods of installing a browser, assuming a user truly do not want to use Trivalent. | ||
|
|
||
| Note that this does not apply as strongly for web-based apps, like those based on Electron. While they also present [significant security concerns](https://github.com/secureblue/secureblue/issues/193#issuecomment-1953323680), the risk is not *as* severe. Usually, there is only one page loaded at a time, and that page is chosen by the publisher of the application. This means there is less necessity for sandboxing processes from each other, in comparison to web browsers which are constantly executing untrusted code from a variety of sources. If you keep the Flatpak permissions strict, they are not a catastrophic risk. That said, we primarily encourage [using PWA alternatives](https://support.google.com/chrome/answer/9658361) when possible, as they benefit from Trivalent's hardening and confinement. |
Contributor
There was a problem hiding this comment.
This makes it sound like the security concerns are with using electron flatpaked, when the security concerns described in the linked comment are about electron in general, even if used outside of a flatpak.
Contributor
Author
There was a problem hiding this comment.
I've rephrased the text surrounding that link.
|
|
||
| Note that this does not apply as strongly for web-based apps, like those based on Electron. While they also present [significant security concerns](https://github.com/secureblue/secureblue/issues/193#issuecomment-1953323680), the risk is not *as* severe. Usually, there is only one page loaded at a time, and that page is chosen by the publisher of the application. This means there is less necessity for sandboxing processes from each other, in comparison to web browsers which are constantly executing untrusted code from a variety of sources. If you keep the Flatpak permissions strict, they are not a catastrophic risk. That said, we primarily encourage [using PWA alternatives](https://support.google.com/chrome/answer/9658361) when possible, as they benefit from Trivalent's hardening and confinement. | ||
|
|
||
| We also block Flatpak browsers from [appearing in Bazaar](https://github.com/secureblue/secureblue/tree/live/files/system/desktop/usr/share/bazaar) to discourage downloading them. You could obtain these flatpaks through other methods if you really want to, but we heavily advise that you don't without a very specific reason to do so. We especially encourage you to avoid Firefox and other Gecko-based flatpaks, as they simply throw up their hands in defeat and [disable a significant part of the internal sandbox](https://bugzilla.mozilla.org/show_bug.cgi?id=1756236). Technically, the Firefox codebase has a warning about this, however, [they intentionally disable the warning](https://hg-edge.mozilla.org/releases/mozilla-beta/rev/509d4746f2d6) in the official Flatpak. |
Contributor
There was a problem hiding this comment.
TBH this section is probably best removed, since it implies that the only reason to avoid Firefox is when it's flatpaked.
Contributor
Author
There was a problem hiding this comment.
I've removed that implication.
| Layer 2 uses [`seccomp-bpf`](https://blog.chromium.org/2012/11/a-safer-playground-for-your-linux-and.html), which restricts the system calls that a process is allowed to send to the kernel. For example, applications often do not need to communicate with device drivers via [`ioctl`](https://en.wikipedia.org/wiki/Ioctl), especially websites. Blocking this call removes a lot of attack surface, as an application could try to exploit a vulnerable driver to escape the sandbox. This idea is expanded to the entire list of system calls, only allowing the [bare minimum needed](https://en.wikipedia.org/wiki/Principle_of_least_privilege) to function. | ||
|
|
||
| These layers combined form a complete sandbox, restricting both what a process can access and what it can do. However, to create this sandbox, a process needs those privileges itself, acting as a broker of permissions to its subprocesses. You cannot enforce the law without authority. This is where Flatpak, or really any attempt to sandbox a browser, begins to cause problems. It's essentially placing the broker, and all of the sandboxes it has made, into one big sandbox. | ||
|
|
Contributor
There was a problem hiding this comment.
A new section on Trivalent's additional confinement via selinux may be appropriate?
Contributor
Author
There was a problem hiding this comment.
That would be good information to have on the site, but it isn't really relevant here. This should remain focused on the difference between a browser inside and outside of Flatpak. Installing Google Chrome via dnf wouldn't benefit from Trivalent's SELinux confinement. Though if that information was added elsewhere, perhaps it could be referenced in the overview in some way as a wink-wink-nudge-nudge-please-just-use-trivalent
Contributor
There was a problem hiding this comment.
I don't see how it's not relevant to an article that covers a variety of bases already. If it's just about the difference between browsers inside and outside a flatpak, then why is there a section on firefox's sandboxing being inferior to chromium's? why is there a section on electron? etc
| ### [Replacing the sandbox](#sandbox-replacing) | ||
| {: #sandbox-replacing} | ||
|
|
||
| Implementations of this sandbox replacement are also of concern. The official Chromium team has no involvement in their development, nor are they providing any oversight or guidance. Instead, these are completely unofficial efforts, and the developers have to keep up with a moving target they don't control, rather than moving along with it as part of Chromium's security model. Instead of being solely focused on security, they inherently also have to focus on making it functional in the first place. |
Contributor
There was a problem hiding this comment.
This is confusing when compared with the previous section, which states that the sandbox can be recreated using flatpak-spawn. So someone reading this could see that and think "why does it need to be replaced when flatpak-spawn can be used?"
Contributor
Author
There was a problem hiding this comment.
I've rephrased somewhat, but I feel the previous section makes it clear what the sandbox replacement is and why it has problems.
| ### [Replacing the sandbox](#sandbox-replacing) | ||
| {: #sandbox-replacing} | ||
|
|
||
| Implementations of this sandbox replacement are also of concern. The official Chromium team has no involvement in their development, nor are they providing any oversight or guidance. Instead, these are completely unofficial efforts, and the developers have to keep up with a moving target they don't control, rather than moving along with it as part of Chromium's security model. Instead of being solely focused on security, they inherently also have to focus on making it functional in the first place. |
Contributor
There was a problem hiding this comment.
Suggested change
| Implementations of this sandbox replacement are also of concern. The official Chromium team has no involvement in their development, nor are they providing any oversight or guidance. Instead, these are completely unofficial efforts, and the developers have to keep up with a moving target they don't control, rather than moving along with it as part of Chromium's security model. Instead of being solely focused on security, they inherently also have to focus on making it functional in the first place. | |
| Implementations of this sandbox replacement are also of concern. The Chromium team has no involvement in their development, nor are they providing any oversight or guidance. Instead, these are unofficial efforts, and the developers have to keep up with a moving target they don't control, rather than moving along with it as part of Chromium's security model. |
Contributor
Author
There was a problem hiding this comment.
I've rephrased the final sentence, and removed the extraneous words.
|
|
||
| Implementations of this sandbox replacement are also of concern. The official Chromium team has no involvement in their development, nor are they providing any oversight or guidance. Instead, these are completely unofficial efforts, and the developers have to keep up with a moving target they don't control, rather than moving along with it as part of Chromium's security model. Instead of being solely focused on security, they inherently also have to focus on making it functional in the first place. | ||
|
|
||
| While sometimes the sandboxing source code is [directly patched](https://github.com/flathub/org.chromium.Chromium/blob/master/patches/chromium/flatpak-Add-initial-sandbox-support.patch), Chromium-based flatpaks typically utilize a workaround shim called [Zypak](https://github.com/refi64/zypak). It essentially tricks Chromium into believing the offical sandbox is present, then intercepts the calls to create a new user namespace, instead creating new processes with Flatpak's sandbox. Workarounds like this, which Chromium has no idea are even happening, mean we're dealing with unintended behavior that the Chromium team isn't accounting for. |
Contributor
There was a problem hiding this comment.
Suggested change
| While sometimes the sandboxing source code is [directly patched](https://github.com/flathub/org.chromium.Chromium/blob/master/patches/chromium/flatpak-Add-initial-sandbox-support.patch), Chromium-based flatpaks typically utilize a workaround shim called [Zypak](https://github.com/refi64/zypak). It essentially tricks Chromium into believing the offical sandbox is present, then intercepts the calls to create a new user namespace, instead creating new processes with Flatpak's sandbox. Workarounds like this, which Chromium has no idea are even happening, mean we're dealing with unintended behavior that the Chromium team isn't accounting for. | |
| While for some flatpaked chromium-based browsers the sandboxing source code is [directly patched](https://github.com/flathub/org.chromium.Chromium/blob/master/patches/chromium/flatpak-Add-initial-sandbox-support.patch) to replace the Layer 1 sandbox, other Chromium-based flatpaks utilize a workaround shim called [Zypak](https://github.com/refi64/zypak). It essentially tricks Chromium into believing the offical sandbox is present, then intercepts the calls to create a new user namespace, instead creating new processes with Flatpak's sandbox. |
Contributor
Author
There was a problem hiding this comment.
I've rephrased the final sentence, and tweaked the opening.
|
|
||
| While sometimes the sandboxing source code is [directly patched](https://github.com/flathub/org.chromium.Chromium/blob/master/patches/chromium/flatpak-Add-initial-sandbox-support.patch), Chromium-based flatpaks typically utilize a workaround shim called [Zypak](https://github.com/refi64/zypak). It essentially tricks Chromium into believing the offical sandbox is present, then intercepts the calls to create a new user namespace, instead creating new processes with Flatpak's sandbox. Workarounds like this, which Chromium has no idea are even happening, mean we're dealing with unintended behavior that the Chromium team isn't accounting for. | ||
|
|
||
| Additionally, these attempts to reimplement the sandbox are much more obscure projects, with no formal security auditing, no formal vulnerability reporting process, and far less eyes watching them. This lack of scrutiny means they're less understood and less tested, and could be significantly weaker, perhaps even having major vulnerabilities which nobody has noticed because nobody has looked. Zypak in particular is [maintained by one person](https://github.com/refi64/zypak/graphs/contributors), which while an impressive undertaking, means they are the sole source of trust for the sandbox. |
Contributor
There was a problem hiding this comment.
This section makes claims it can't substantiate. How do you know they aren't being formally audited? And how do they not have formal reporting processes?
Contributor
There was a problem hiding this comment.
This section is probably best removed
Contributor
Author
There was a problem hiding this comment.
I've substantiated the claims.
|
|
||
| Additionally, these attempts to reimplement the sandbox are much more obscure projects, with no formal security auditing, no formal vulnerability reporting process, and far less eyes watching them. This lack of scrutiny means they're less understood and less tested, and could be significantly weaker, perhaps even having major vulnerabilities which nobody has noticed because nobody has looked. Zypak in particular is [maintained by one person](https://github.com/refi64/zypak/graphs/contributors), which while an impressive undertaking, means they are the sole source of trust for the sandbox. | ||
|
|
||
| Meanwhile, the Chromium sandbox is maintained by an entire team of professionals who have been involved for years, building off all the [long battle-tested](https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html) work done since [2006](https://blog.chromium.org/2018/09/how-we-designed-chrome-10-years-ago.html), as their work is watched by the countless projects which rely on it. Chromium is easily one of the most used codebases in the world, and countless individuals, organizations, businesses, and governments have a lot of stake in making sure it works safely. |
Contributor
There was a problem hiding this comment.
entire team of professionals
How do we know this is the case?
Contributor
There was a problem hiding this comment.
This section is also probably best removed as it makes claims that can't be substantiated
Contributor
Author
There was a problem hiding this comment.
I've substantiated the claims.
Contributor
There was a problem hiding this comment.
The link used to substantiate it is not updated with any regularity. And the new substantiation is mostly just editorializing or not security relevant, like:
They may even have major vulnerabilities which nobody has found because nobody has looked
Chromium is one of the [most used codebases in the world]
I don't think either of these sections about team size or usage should be present, they should be removed as their function is primarily to editorialize. We should be evaluating technical merit and demerit only.
| ### [Conclusion](#conclusion) | ||
| {: #conclusion} | ||
|
|
||
| None of this is necessarily a flaw in Flatpak. The restrictions causing these problems are exactly [what makes its sandboxing effective](https://github.com/flatpak/flatpak/issues/5879#issuecomment-2255568180). The problem is trying to sandbox a sandbox. Flatpak is designed to sandbox applications which are designed to be privileged already. For that purpose, it can work quite well, which is why we use it, and we encourage usage of it. But when an application is already designed with security in mind, using its own privilege to restrict itself, taking away that privilege leads to significant challenges. |
Contributor
There was a problem hiding this comment.
Flatpak is designed to sandbox applications which are designed to be privileged already.
This sentence is confusing and also not exactly accurate depending on what you mean by privileged
Contributor
Author
There was a problem hiding this comment.
I've rephrased that sentence.
|
|
||
| None of this is necessarily a flaw in Flatpak. The restrictions causing these problems are exactly [what makes its sandboxing effective](https://github.com/flatpak/flatpak/issues/5879#issuecomment-2255568180). The problem is trying to sandbox a sandbox. Flatpak is designed to sandbox applications which are designed to be privileged already. For that purpose, it can work quite well, which is why we use it, and we encourage usage of it. But when an application is already designed with security in mind, using its own privilege to restrict itself, taking away that privilege leads to significant challenges. | ||
|
|
||
| While we don't want to make this an appeal to authority argument, these concerns don't just come from us, they have also been raised by the [Vivaldi developers](https://forum.vivaldi.net/topic/33411/flatpak-support/191), the [Brave developers](https://brave.com/linux/#:~:text=it%20modifies%20Chromium%20sandboxing%20in%20ways%20which%20have%20not%20been%20vetted%20by%20the%20Brave%20or%20Chromium%20security%20teams), the [Helium developers](https://github.com/imputnet/helium-linux/issues/46#issuecomment-3735501507), the [Cromite developers](https://github.com/uazo/cromite/issues/1053#issuecomment-2191794660), the [Tails developers](https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1025#note_253065), and even the [Chromium developers themselves](https://issues.chromium.org/issues/40753165#comment11). Many projects have expressed interest in making a Flatpak package, and would see benefit from doing so, but are wary of officially endorsing this method of sandboxing. |
Contributor
There was a problem hiding this comment.
Suggested change
| While we don't want to make this an appeal to authority argument, these concerns don't just come from us, they have also been raised by the [Vivaldi developers](https://forum.vivaldi.net/topic/33411/flatpak-support/191), the [Brave developers](https://brave.com/linux/#:~:text=it%20modifies%20Chromium%20sandboxing%20in%20ways%20which%20have%20not%20been%20vetted%20by%20the%20Brave%20or%20Chromium%20security%20teams), the [Helium developers](https://github.com/imputnet/helium-linux/issues/46#issuecomment-3735501507), the [Cromite developers](https://github.com/uazo/cromite/issues/1053#issuecomment-2191794660), the [Tails developers](https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1025#note_253065), and even the [Chromium developers themselves](https://issues.chromium.org/issues/40753165#comment11). Many projects have expressed interest in making a Flatpak package, and would see benefit from doing so, but are wary of officially endorsing this method of sandboxing. | |
| These concerns are shared by other browser projects. For example, [Vivaldi](https://forum.vivaldi.net/topic/33411/flatpak-support/191), [Brave](https://brave.com/linux/#:~:text=it%20modifies%20Chromium%20sandboxing%20in%20ways%20which%20have%20not%20been%20vetted%20by%20the%20Brave%20or%20Chromium%20security%20teams), [Helium](https://github.com/imputnet/helium-linux/issues/46#issuecomment-3735501507), [Cromite](https://github.com/uazo/cromite/issues/1053#issuecomment-2191794660), and [Chromium](https://issues.chromium.org/issues/40753165#comment11). |
Contributor
Author
There was a problem hiding this comment.
I've rephrased the beginning and end. I disagree with the changes to the links. The choice in phrasing was deliberate to make the separation and intent of the links clear. The plaintext "the" provides more visual separation between each one, whereas otherwise they could more easily blend together and appear as one massive link. The word "developers" is there to make it more implicitly obvious that it links to various statements, rather than links to what each of those entities are, while also providing additional surface area to click them rather than consisting of one fairly small word each.
Contributor
There was a problem hiding this comment.
they could more easily blend together and appear as one massive link.
why would that be? they would be comma separated
Contributor
There was a problem hiding this comment.
Also I had intentionally removed some of the links 😅
|
|
||
| While we don't want to make this an appeal to authority argument, these concerns don't just come from us, they have also been raised by the [Vivaldi developers](https://forum.vivaldi.net/topic/33411/flatpak-support/191), the [Brave developers](https://brave.com/linux/#:~:text=it%20modifies%20Chromium%20sandboxing%20in%20ways%20which%20have%20not%20been%20vetted%20by%20the%20Brave%20or%20Chromium%20security%20teams), the [Helium developers](https://github.com/imputnet/helium-linux/issues/46#issuecomment-3735501507), the [Cromite developers](https://github.com/uazo/cromite/issues/1053#issuecomment-2191794660), the [Tails developers](https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1025#note_253065), and even the [Chromium developers themselves](https://issues.chromium.org/issues/40753165#comment11). Many projects have expressed interest in making a Flatpak package, and would see benefit from doing so, but are wary of officially endorsing this method of sandboxing. | ||
|
|
||
| As such, until Flatpak has the necessary features to allow proper internal sandboxing, and browsers begin *officially* implementing it, we will continue to strongly recommend against usage of browsers installed via Flatpak. While we will always primarily recommend using Trivalent, especially since much of secureblue's hardening efforts revolve around it; there are valid reasons to want to install another browser, and we want to make sure that's done in the safest manner available. Unfortunately, that is not Flatpak. |
Contributor
There was a problem hiding this comment.
Suggested change
| As such, until Flatpak has the necessary features to allow proper internal sandboxing, and browsers begin *officially* implementing it, we will continue to strongly recommend against usage of browsers installed via Flatpak. While we will always primarily recommend using Trivalent, especially since much of secureblue's hardening efforts revolve around it; there are valid reasons to want to install another browser, and we want to make sure that's done in the safest manner available. Unfortunately, that is not Flatpak. | |
| Until Flatpak has the necessary features to allow browser sandboxes to function properly, we will continue to strongly recommend against usage of Flatpaked browsers. |
Contributor
Author
There was a problem hiding this comment.
I've rephrased the ending.
| ### [Conclusion](#conclusion) | ||
| {: #conclusion} | ||
|
|
||
| None of this is necessarily a flaw in Flatpak. The restrictions causing these problems are exactly [what makes its sandboxing effective](https://github.com/flatpak/flatpak/issues/5879#issuecomment-2255568180). The problem is trying to sandbox a sandbox. Flatpak is designed to sandbox applications which are designed to be privileged already. For that purpose, it can work quite well, which is why we use it, and we encourage usage of it. But when an application is already designed with security in mind, using its own privilege to restrict itself, taking away that privilege leads to significant challenges. |
Contributor
There was a problem hiding this comment.
Suggested change
| None of this is necessarily a flaw in Flatpak. The restrictions causing these problems are exactly [what makes its sandboxing effective](https://github.com/flatpak/flatpak/issues/5879#issuecomment-2255568180). The problem is trying to sandbox a sandbox. Flatpak is designed to sandbox applications which are designed to be privileged already. For that purpose, it can work quite well, which is why we use it, and we encourage usage of it. But when an application is already designed with security in mind, using its own privilege to restrict itself, taking away that privilege leads to significant challenges. | |
| It's important to note that the Flatpak restriction that causes this problem is part of [what makes Flatpak's sandboxing effective](https://github.com/flatpak/flatpak/issues/5879#issuecomment-2255568180). The problem is trying to sandbox an application that uses the same tools for its own internal sandboxing. ...etc |
Contributor
Author
There was a problem hiding this comment.
I've rephrased this section.
| ### [Conclusion](#conclusion) | ||
| {: #conclusion} | ||
|
|
||
| None of this is necessarily a flaw in Flatpak. The restrictions causing these problems are exactly [what makes its sandboxing effective](https://github.com/flatpak/flatpak/issues/5879#issuecomment-2255568180). The problem is trying to sandbox a sandbox. Flatpak is designed to sandbox applications which are designed to be privileged already. For that purpose, it can work quite well, which is why we use it, and we encourage usage of it. But when an application is already designed with security in mind, using its own privilege to restrict itself, taking away that privilege leads to significant challenges. |
Contributor
There was a problem hiding this comment.
For that purpose, it can work quite well, which is why we use it, and we encourage usage of it.
This sentence can be removed
Contributor
Author
There was a problem hiding this comment.
I've rephrased the first half and removed the second. I feel the first half matters for the flow of the paragraph, especially as written now.
|
|
||
| As of now, Flatpak restricts the ability for applications to create user namespaces [within the Flatpak sandbox](https://github.com/flatpak/flatpak/blob/6dfe1ad4d0a4c0bd9b1c44294aeeac903b0d3bf4/common/flatpak-run.c#L2349). This means Layer 1 of the browser sandbox cannot function. To recreate it, the browser must instead use the [`flatpak-spawn`](https://docs.flatpak.org/en/latest/flatpak-command-reference.html#flatpak-spawn) API, essentially asking Flatpak to make a new user namespace for a subprocess it wants to make. However, Flatpak controls this new namespace, not the browser. This makes it difficult to restrict the capabilities of the subprocess beyond what Flatpak already does, weakening Layer 2. | ||
|
|
||
| Essentially, by making a browser a flatpak, the sandbox designed for the browser has to be replaced with the general purpose Flatpak sandbox. By being general purpose, Flatpak needs to be looser with permissions to allow a variety of things to function. For example, for an app to access the internet, Flatpak needs a hole in the sandbox for packets to go through. But this hole is open for the entire sandbox, even if certain things don't need access to it. The browser-specific sandbox can be finely tuned to exactly what its processes need and no more. It can restrict internet access to a special process for packet traffic, and pass them along to other processes which don't need internet access. |
Contributor
There was a problem hiding this comment.
This section is confusing in large part due to the conflation of internal and external sandboxing, and layer 1 and layer 2 internal sandboxing, all as a "sandbox"
Contributor
Author
There was a problem hiding this comment.
I've tried to remedy where your confusion might lie, relying less on the context provided in the preceding paragraph.
|
|
||
| As of now, Flatpak restricts the ability for applications to create user namespaces [within the Flatpak sandbox](https://github.com/flatpak/flatpak/blob/6dfe1ad4d0a4c0bd9b1c44294aeeac903b0d3bf4/common/flatpak-run.c#L2349). This means Layer 1 of the browser sandbox cannot function. To recreate it, the browser must instead use the [`flatpak-spawn`](https://docs.flatpak.org/en/latest/flatpak-command-reference.html#flatpak-spawn) API, essentially asking Flatpak to make a new user namespace for a subprocess it wants to make. However, Flatpak controls this new namespace, not the browser. This makes it difficult to restrict the capabilities of the subprocess beyond what Flatpak already does, weakening Layer 2. | ||
|
|
||
| Essentially, by making a browser a flatpak, the sandbox designed for the browser has to be replaced with the general purpose Flatpak sandbox. By being general purpose, Flatpak needs to be looser with permissions to allow a variety of things to function. For example, for an app to access the internet, Flatpak needs a hole in the sandbox for packets to go through. But this hole is open for the entire sandbox, even if certain things don't need access to it. The browser-specific sandbox can be finely tuned to exactly what its processes need and no more. It can restrict internet access to a special process for packet traffic, and pass them along to other processes which don't need internet access. |
Contributor
There was a problem hiding this comment.
Suggested change
| Essentially, by making a browser a flatpak, the sandbox designed for the browser has to be replaced with the general purpose Flatpak sandbox. By being general purpose, Flatpak needs to be looser with permissions to allow a variety of things to function. For example, for an app to access the internet, Flatpak needs a hole in the sandbox for packets to go through. But this hole is open for the entire sandbox, even if certain things don't need access to it. The browser-specific sandbox can be finely tuned to exactly what its processes need and no more. It can restrict internet access to a special process for packet traffic, and pass them along to other processes which don't need internet access. | |
| When making a Flatpak package for a browser,... etc |
Also, Flatpak vs flatpak capitalization consistency
Contributor
Author
There was a problem hiding this comment.
I believe all instances should now abide by proper noun and common noun rules.
|
|
||
| Layer 2 uses [`seccomp-bpf`](https://blog.chromium.org/2012/11/a-safer-playground-for-your-linux-and.html), which restricts the system calls that a process is allowed to send to the kernel. For example, applications often do not need to communicate with device drivers via [`ioctl`](https://en.wikipedia.org/wiki/Ioctl), especially websites. Blocking this call removes a lot of attack surface, as an application could try to exploit a vulnerable driver to escape the sandbox. This idea is expanded to the entire list of system calls, only allowing the [bare minimum needed](https://en.wikipedia.org/wiki/Principle_of_least_privilege) to function. | ||
|
|
||
| These layers combined form a complete sandbox, restricting both what a process can access and what it can do. However, to create this sandbox, a process needs those privileges itself, acting as a broker of permissions to its subprocesses. You cannot enforce the law without authority. This is where Flatpak, or really any attempt to sandbox a browser, begins to cause problems. It's essentially placing the broker, and all of the sandboxes it has made, into one big sandbox. |
Contributor
There was a problem hiding this comment.
what a process can access and what it can do
What does this mean in practice?
Contributor
Author
There was a problem hiding this comment.
I've added clarification on how that ties into the immediately preceding paragraphs.
no change in final result, just easier to read as raw markdown https://kramdown.gettalong.org/syntax.html#reference-links
| - [User namespaces](/articles/userns) - Brief overview of unprivileged User Namespaces, the security risk they enabled and how secureblue handles that risk. | ||
| - [Kernel arguments](/articles/kargs) - List and brief explanation of the hardening kargs that the `ujust set-kargs-hardening` command can set. | ||
| - [Flatpak](/articles/flatpak) - Flatpak: the good, the bad, the ugly. | ||
| - [Flatpak web browsers](/articles/flatpak-browsers) - The struggles of keeping the web sandboxed within a sandbox |
Contributor
There was a problem hiding this comment.
A more descriptive subtext here would be good
Also, (nit) it should end with a period
Contributor
Author
There was a problem hiding this comment.
More descriptive than "Flatpak: the good, the bad, the ugly"? :P I think it gives you a good idea of what the article is about, which is "flatpak browser bad"
Contributor
There was a problem hiding this comment.
Yes because it's not a "struggle"
|
|
||
| - [Overview](#overview) | ||
| - [Technical details](#technical) | ||
| - [How browser sandboxing works](#sandboxing-explained) |
Contributor
There was a problem hiding this comment.
Maybe "Browser sandboxing overview"
Contributor
Author
There was a problem hiding this comment.
I dunno, that feels overly rigid. And something feels wrong about reusing the word overview. I think the current headers are naturally intuitive to read and understand what's inside.
Contributor
There was a problem hiding this comment.
It's not really an appropriate subheading for a technical document. If anything the heading should just be "Browser sandboxing" since the header is already "Technical details"
| ## [Overview](#overview) | ||
| {: #overview} | ||
|
|
||
| While we generally encourage Flatpak usage, this is *not* the case for web browsers. Currently, they are incapable of reaching the same level of security within the Flatpak sandbox. This [could change in the future][flatpak-userns], but right now, there are a lot of reasons to be concerned. As such, we consider it safest to avoid them entirely, and we encourage using other methods of installing a browser, assuming a user truly do not want to use Trivalent. |
Contributor
There was a problem hiding this comment.
flatpak-userns doesn't appear to link to anything?
Contributor
Author
There was a problem hiding this comment.
| ## [Overview](#overview) | ||
| {: #overview} | ||
|
|
||
| While we generally encourage Flatpak usage, this is *not* the case for web browsers. Currently, they are incapable of reaching the same level of security within the Flatpak sandbox. This [could change in the future][flatpak-userns], but right now, there are a lot of reasons to be concerned. As such, we consider it safest to avoid them entirely, and we encourage using other methods of installing a browser, assuming a user truly do not want to use Trivalent. |
Contributor
There was a problem hiding this comment.
but right now, there are a lot of reasons to be concerned.
This can be removed
Contributor
Author
There was a problem hiding this comment.
I've rephrased this section.
|
|
||
| Note that this does not apply as strongly for web-based apps, like those based on Electron. While Electron presents [significant security concerns][electron-concerns], the risks that come from it being flatpaked are not *as* severe as with web browsers. Usually, there is only one page loaded at a time, and that page is chosen by the publisher of the application. This means there is less necessity for sandboxing processes from each other, in comparison to web browsers which are constantly executing untrusted code from a variety of sources. If you keep the Flatpak permissions strict, they are not a catastrophic risk. That said, we primarily encourage [using PWA alternatives][pwa-guide] when possible, as they benefit from Trivalent's hardening and confinement. | ||
|
|
||
| We block Flatpak browsers from [appearing in Bazaar][bazaar-blocklist] to discourage downloading them. You could obtain these flatpaks through other methods if you really want to, but we heavily advise that you don't without a very specific reason to do so. We especially encourage you to avoid Firefox and other Gecko-based flatpaks. On top of Firefox's internal sandbox already being [weaker than the Chromium sandbox][firefox], <!-- this link should be replaced with our own article later --> within flatpaks they simply throw up their hands in defeat and [disable a significant part of the internal sandbox][ff-nosandbox]. Technically, the Firefox codebase has a warning about this, however, [they intentionally disable the warning][ff-nowarning] in official flatpaks. |
Contributor
There was a problem hiding this comment.
are these inline links supposed to be references? why not just link to the target?
Contributor
Author
There was a problem hiding this comment.
Nope, reference links, like I put in the commit description. Doesn't change the rendered output (i checked), just makes this file a lot easier to read in its raw Markdown form, without having to skim past lots of lengthy URLs.
https://kramdown.gettalong.org/syntax.html#reference-links
In fairness, the footnote syntax is very similar, but those use ^ at the beginning of the name. https://kramdown.gettalong.org/syntax.html#footnotes
Contributor
There was a problem hiding this comment.
just makes this file a lot easier to read in its raw Markdown form
I find it makes it much harder to read/review because i have to scroll to the bottom of the file to check which link is linked
|
|
||
| While we encourage Flatpak usage for general applications, this is *not* the case for web browsers. Currently, when compared to their native packages, they are incapable of reaching the same level of security within the Flatpak sandbox. This [could change in the future][flatpak-userns], but for the time being, we consider it safest to avoid them entirely. Instead, we encourage using other methods of installing a browser. We heavily recommend using Trivalent, and much of our efforts revolve around it, but we cannot stop users from installing another browser. | ||
|
|
||
| Note that this does not apply as strongly for web-based apps, like those based on Electron. While Electron presents [significant security concerns][electron-concerns], the risks that come from it being flatpaked are not *as* severe as with web browsers. Usually, there is only one page loaded at a time, and that page is chosen by the publisher of the application. This means there is less necessity for sandboxing processes from each other, in comparison to web browsers which are constantly executing untrusted code from a variety of sources. If you keep the Flatpak permissions strict, they are not a catastrophic risk. That said, we primarily encourage [using PWA alternatives][pwa-guide] when possible, as they benefit from Trivalent's hardening and confinement. |
Contributor
There was a problem hiding this comment.
instead of "web-based apps", "apps using a web frontend stack" is probably more appropriate
|
|
||
| While we encourage Flatpak usage for general applications, this is *not* the case for web browsers. Currently, when compared to their native packages, they are incapable of reaching the same level of security within the Flatpak sandbox. This [could change in the future][flatpak-userns], but for the time being, we consider it safest to avoid them entirely. Instead, we encourage using other methods of installing a browser. We heavily recommend using Trivalent, and much of our efforts revolve around it, but we cannot stop users from installing another browser. | ||
|
|
||
| Note that this does not apply as strongly for web-based apps, like those based on Electron. While Electron presents [significant security concerns][electron-concerns], the risks that come from it being flatpaked are not *as* severe as with web browsers. Usually, there is only one page loaded at a time, and that page is chosen by the publisher of the application. This means there is less necessity for sandboxing processes from each other, in comparison to web browsers which are constantly executing untrusted code from a variety of sources. If you keep the Flatpak permissions strict, they are not a catastrophic risk. That said, we primarily encourage [using PWA alternatives][pwa-guide] when possible, as they benefit from Trivalent's hardening and confinement. |
Contributor
There was a problem hiding this comment.
On second look, this section is just not particularly accurate. Electron apps can load multiple pages at a time using browserviews or webviews. The page being chosen by the publisher of the app is also not particularly relevant because that's true of every website, and electron apps and websites alike load content from various third parties
Contributor
There was a problem hiding this comment.
This section should probably just be removed and we should just note that we allow electron apps through because of their ubiquity but they should still be avoided.
|
|
||
| Note that this does not apply as strongly for web-based apps, like those based on Electron. While Electron presents [significant security concerns][electron-concerns], the risks that come from it being flatpaked are not *as* severe as with web browsers. Usually, there is only one page loaded at a time, and that page is chosen by the publisher of the application. This means there is less necessity for sandboxing processes from each other, in comparison to web browsers which are constantly executing untrusted code from a variety of sources. If you keep the Flatpak permissions strict, they are not a catastrophic risk. That said, we primarily encourage [using PWA alternatives][pwa-guide] when possible, as they benefit from Trivalent's hardening and confinement. | ||
|
|
||
| We block Flatpak browsers from [appearing in Bazaar][bazaar-blocklist] to discourage downloading them. You could obtain these flatpaks through other methods if you really want to, but we heavily advise that you don't without a very specific reason to do so. We especially encourage you to avoid Firefox and other Gecko-based flatpaks. On top of Firefox's internal sandbox already being [weaker than the Chromium sandbox][firefox], <!-- this link should be replaced with our own article later --> within flatpaks they simply throw up their hands in defeat and [disable a significant part of the internal sandbox][ff-nosandbox]. Technically, the Firefox codebase has a warning about this, however, [they intentionally disable the warning][ff-nowarning] in official flatpaks. |
Contributor
There was a problem hiding this comment.
Suggested change
| We block Flatpak browsers from [appearing in Bazaar][bazaar-blocklist] to discourage downloading them. You could obtain these flatpaks through other methods if you really want to, but we heavily advise that you don't without a very specific reason to do so. We especially encourage you to avoid Firefox and other Gecko-based flatpaks. On top of Firefox's internal sandbox already being [weaker than the Chromium sandbox][firefox], <!-- this link should be replaced with our own article later --> within flatpaks they simply throw up their hands in defeat and [disable a significant part of the internal sandbox][ff-nosandbox]. Technically, the Firefox codebase has a warning about this, however, [they intentionally disable the warning][ff-nowarning] in official flatpaks. | |
| We block Flatpak browsers from [appearing in Bazaar][bazaar-blocklist] to discourage downloading them. You could obtain these flatpaks through other methods, but we strongly advise against it. In particular, we advise against Firefox and other Gecko-based Flatpaks. Firefox's internal sandbox and site isolation are substantially [weaker than the Chromium sandbox][firefox]. <!-- this link should be replaced with our own article later --> Within a Flatpak, Firefox [disables][ff-nosandbox] a significant part of the already weaker internal sandbox. The Firefox codebase has a warning about this, however, the warning is [intentionally disabled][ff-nowarning] in official Flatpaks. |
| ### [How Flatpak's sandbox affects browsers](#flatpak-sandbox) | ||
| {: #flatpak-sandbox} | ||
|
|
||
| As of now, Flatpak restricts the ability for applications to create user namespaces [within the Flatpak sandbox][flatpak-userns-block]. This means Layer 1 of the browser sandbox cannot function as intended. Instead, the [`flatpak-spawn`][flatpak-spawn] API must be used as a substitute, essentially asking Flatpak to make a new user namespace for a subprocess it wants to make. However, Flatpak controls this new namespace, not the browser. This makes it difficult to restrict the capabilities of the subprocess beyond what Flatpak already does, weakening Layer 2. |
Contributor
There was a problem hiding this comment.
Suggested change
| As of now, Flatpak restricts the ability for applications to create user namespaces [within the Flatpak sandbox][flatpak-userns-block]. This means Layer 1 of the browser sandbox cannot function as intended. Instead, the [`flatpak-spawn`][flatpak-spawn] API must be used as a substitute, essentially asking Flatpak to make a new user namespace for a subprocess it wants to make. However, Flatpak controls this new namespace, not the browser. This makes it difficult to restrict the capabilities of the subprocess beyond what Flatpak already does, weakening Layer 2. | |
| As of May 2026, Flatpak restricts the ability for applications to create user namespaces [within the Flatpak sandbox][flatpak-userns-block]. This means Layer 1 of the browser sandbox cannot function as intended. Instead, the [`flatpak-spawn`][flatpak-spawn] API must be used as a substitute, essentially asking Flatpak to make a new user namespace for a subprocess it wants to make. However, Flatpak controls this new namespace, not the browser. This makes it difficult to restrict the capabilities of the subprocess beyond what Flatpak already does, weakening Layer 2. |
| ### [How Flatpak's sandbox affects browsers](#flatpak-sandbox) | ||
| {: #flatpak-sandbox} | ||
|
|
||
| As of now, Flatpak restricts the ability for applications to create user namespaces [within the Flatpak sandbox][flatpak-userns-block]. This means Layer 1 of the browser sandbox cannot function as intended. Instead, the [`flatpak-spawn`][flatpak-spawn] API must be used as a substitute, essentially asking Flatpak to make a new user namespace for a subprocess it wants to make. However, Flatpak controls this new namespace, not the browser. This makes it difficult to restrict the capabilities of the subprocess beyond what Flatpak already does, weakening Layer 2. |
Contributor
There was a problem hiding this comment.
This makes it difficult to restrict the capabilities of the subprocess beyond what Flatpak already does, weakening Layer 2.
Can a technical reference be added for this?
| ### [Substituting the sandbox](#sandbox-substituting) | ||
| {: #sandbox-substituting} | ||
|
|
||
| Implementations of this modified sandbox are also of concern. The Chromium team has no involvement in their development, nor are they providing any oversight or guidance. Instead, these are unofficial efforts, and the developers have to keep up with a moving target they don't control, rather than moving along with it as part of Chromium's security model. They inherently have to be extra vigilant that compatibility isn't broken across updates, distracting from being able to strictly prioritize security. |
Contributor
There was a problem hiding this comment.
They inherently have to be extra vigilant that compatibility isn't broken across updates, distracting from being able to strictly prioritize security.
This is editorializing and should be removed
|
|
||
| Implementations of this modified sandbox are also of concern. The Chromium team has no involvement in their development, nor are they providing any oversight or guidance. Instead, these are unofficial efforts, and the developers have to keep up with a moving target they don't control, rather than moving along with it as part of Chromium's security model. They inherently have to be extra vigilant that compatibility isn't broken across updates, distracting from being able to strictly prioritize security. | ||
|
|
||
| While in some cases the Layer 1 sandbox code is [directly patched][sandbox-patch], most Chromium-based flatpaks utilize a workaround shim called [Zypak][zypak]. It essentially tricks Chromium into believing the offical sandbox is present, then intercepts the calls to create a new user namespace, instead creating new processes with Flatpak's sandbox. Workarounds like this, which the Chromium team isn't accounting for, can lead to unintended behavior and breakage. |
Contributor
There was a problem hiding this comment.
Suggested change
| While in some cases the Layer 1 sandbox code is [directly patched][sandbox-patch], most Chromium-based flatpaks utilize a workaround shim called [Zypak][zypak]. It essentially tricks Chromium into believing the offical sandbox is present, then intercepts the calls to create a new user namespace, instead creating new processes with Flatpak's sandbox. Workarounds like this, which the Chromium team isn't accounting for, can lead to unintended behavior and breakage. | |
| While in some cases the Layer 1 sandbox code is [directly patched][sandbox-patch], most Chromium-based flatpaks utilize a workaround shim called [Zypak][zypak]. It essentially tricks Chromium into believing the offical sandbox is present, then intercepts the calls to create a new user namespace, instead creating new processes with Flatpak's sandbox. |
Removed a sentence that restates the topic of the previous paragraph
| [sandbox-patch]: https://github.com/flathub/org.chromium.Chromium/blob/master/patches/chromium/flatpak-Add-initial-sandbox-support.patch | ||
| [zypak]: https://github.com/refi64/zypak | ||
| [zypak-contribs]: https://github.com/refi64/zypak/graphs/contributors | ||
| [chromium-secteam]: https://www.chromium.org/Home/chromium-security/brag-sheet/ |
Contributor
There was a problem hiding this comment.
This is not a reliable reference. This site is rarely updated and has dead links from 2011
| ### [Conclusion](#conclusion) | ||
| {: #conclusion} | ||
|
|
||
| It's important to note that none of this is necessarily a flaw in Flatpak. The restriction that causes this problem is part of [what makes Flatpak's sandboxing effective][why-no-userns]. The problem is trying to sandbox an application which uses the same tools to sandbox itself. Flatpak is designed to accomodate applications which don't expect a restricted environment, and aren't concerned with creating a restricted environment. For that purpose, it can be very effective. But when an application is already designed with security in mind, using its own privilege to restrict itself, taking away that privilege leads to significant challenges. |
Contributor
There was a problem hiding this comment.
Suggested change
| It's important to note that none of this is necessarily a flaw in Flatpak. The restriction that causes this problem is part of [what makes Flatpak's sandboxing effective][why-no-userns]. The problem is trying to sandbox an application which uses the same tools to sandbox itself. Flatpak is designed to accomodate applications which don't expect a restricted environment, and aren't concerned with creating a restricted environment. For that purpose, it can be very effective. But when an application is already designed with security in mind, using its own privilege to restrict itself, taking away that privilege leads to significant challenges. | |
| It's important to note that none of this is necessarily a flaw in Flatpak. The restriction on [user namespaces](/articles/userns) within Flatpaks is necessary for Flatpak's sandboxing to be [effective][why-no-userns]. The problem arises when trying to sandbox an application that internally uses user namespaces to sandbox itself. When an application is already designed with security in mind and uses user namespace privileges to sandbox itself, taking away those privileges introduces security issues. |
Flatpak is designed to accommodate applications which don't expect a restricted environment, and aren't concerned with creating a restricted environment
This implies that it isn't designed to accommodate applications which do expect a restricted environment? I'm not really following but this isn't substantiated anyhow (we don't have a reference linked regarding design goals of flatpak) so I removed it
very effective
This is way too strong 😅
|
|
||
| It's important to note that none of this is necessarily a flaw in Flatpak. The restriction that causes this problem is part of [what makes Flatpak's sandboxing effective][why-no-userns]. The problem is trying to sandbox an application which uses the same tools to sandbox itself. Flatpak is designed to accomodate applications which don't expect a restricted environment, and aren't concerned with creating a restricted environment. For that purpose, it can be very effective. But when an application is already designed with security in mind, using its own privilege to restrict itself, taking away that privilege leads to significant challenges. | ||
|
|
||
| These are not exclusively our concerns, they are shared by a number of others, including the [Vivaldi developers][vivaldi], the [Brave developers][brave], the [Helium developers][helium], the [Cromite developers][cromite], the [Tails developers][tails], and even the [Chromium developers themselves][chromium-team-response]. A number of browser projects are wary of making a Flatpak package, because it would mean officially endorsing this method of sandboxing. |
Contributor
There was a problem hiding this comment.
this method of sandboxing.
What method? This paragraph isn't discussing a particular method
|
|
||
| These are not exclusively our concerns, they are shared by a number of others, including the [Vivaldi developers][vivaldi], the [Brave developers][brave], the [Helium developers][helium], the [Cromite developers][cromite], the [Tails developers][tails], and even the [Chromium developers themselves][chromium-team-response]. A number of browser projects are wary of making a Flatpak package, because it would mean officially endorsing this method of sandboxing. | ||
|
|
||
| Until Flatpak has the necessary features to allow internal browser sandboxes to function as intended, we will continue to strongly recommend against usage of flatpaked browsers. The Flatpak maintainers have stated this is something they're working on, but it will take time for it to be implemented, and for it to be adopted by browsers. Until that time comes, it's important to inform them there are much safer methods available than Flatpak as it is now. |
Contributor
There was a problem hiding this comment.
Suggested change
| Until Flatpak has the necessary features to allow internal browser sandboxes to function as intended, we will continue to strongly recommend against usage of flatpaked browsers. The Flatpak maintainers have stated this is something they're working on, but it will take time for it to be implemented, and for it to be adopted by browsers. Until that time comes, it's important to inform them there are much safer methods available than Flatpak as it is now. | |
| Until Flatpak has the necessary features to allow internal browser sandboxes to function as intended, we will continue to strongly recommend against usage of flatpaked browsers. The Flatpak maintainers have stated that this is something they're working on, but it will take time for it to be implemented and adopted by browsers. Until then, Flatpaked browsers should be avoided. |
them
who?
|
|
||
| While in some cases the Layer 1 sandbox code is [directly patched][sandbox-patch], most Chromium-based flatpaks utilize a workaround shim called [Zypak][zypak]. It essentially tricks Chromium into believing the offical sandbox is present, then intercepts the calls to create a new user namespace, instead creating new processes with Flatpak's sandbox. Workarounds like this, which the Chromium team isn't accounting for, can lead to unintended behavior and breakage. | ||
|
|
||
| These sandbox substitutions also have much smaller teams. Zypak in particular is [maintained by one person][zypak-contribs], which while an impressive undertaking, means they become the sole source of trust for the sandbox functioning properly. Meanwhile, the Chromium sandbox is maintained by an [entire team of professionals][chromium-secteam] who have been involved for years, building off all the [long battle-tested][vuln-lifespan] work done since [2006][chrome-origin], as they [constantly watch][shephard] to identify issues quickly. |
Contributor
There was a problem hiding this comment.
As mentioned, this and the subsequent section should be removed
|
|
||
| As of now, Flatpak restricts the ability for applications to create user namespaces [within the Flatpak sandbox][flatpak-userns-block]. This means Layer 1 of the browser sandbox cannot function as intended. Instead, the [`flatpak-spawn`][flatpak-spawn] API must be used as a substitute, essentially asking Flatpak to make a new user namespace for a subprocess it wants to make. However, Flatpak controls this new namespace, not the browser. This makes it difficult to restrict the capabilities of the subprocess beyond what Flatpak already does, weakening Layer 2. | ||
|
|
||
| When making a Flatpak package for a browser, a highly specialized part of the internal sandbox has to be replaced with the general purpose Flatpak sandbox. By being general purpose, Flatpak needs to be looser with permissions to allow a variety of things to function. For example, for an app to access the internet, Flatpak needs a hole in the sandbox for packets to go through. However, not every process needs access to this hole, and it's more difficult to granularly restrict what can access it. The browser-specific sandbox is only designed around one application, so it can be finely tuned to exactly what its processes need and no more. For example, it can restrict internet access to a special process for packet traffic, and pass them along to other processes which don't need internet access. |
Contributor
There was a problem hiding this comment.
Suggested change
| When making a Flatpak package for a browser, a highly specialized part of the internal sandbox has to be replaced with the general purpose Flatpak sandbox. By being general purpose, Flatpak needs to be looser with permissions to allow a variety of things to function. For example, for an app to access the internet, Flatpak needs a hole in the sandbox for packets to go through. However, not every process needs access to this hole, and it's more difficult to granularly restrict what can access it. The browser-specific sandbox is only designed around one application, so it can be finely tuned to exactly what its processes need and no more. For example, it can restrict internet access to a special process for packet traffic, and pass them along to other processes which don't need internet access. | |
| In a Flatpaked Chromium-based browser, a highly specialized part of the internal sandbox is substituted with Flatpak's general-purpose sandbox. By general purpose, we mean that Flatpak needs to be flexible enough for a variety of application types to function. For example, for an app to access the internet, Flatpak needs a hole in the sandbox for packets to go through. However, not every process within an application necessarily needs access to this hole, and Flatpak doesn't provide mechanisms to granularly restrict which subprocesses can access it. On the other hand, the Chromium-specific sandbox is only designed around one application, so it can be finely tuned to allow exactly what its processes need and no more. For example, it can restrict internet access to a special process for packet traffic and then pass that traffic along to other processes which don't need internet access. |
When making
This shouldn't be written from the point of view of a flatpak packager
Highly specialized
A technical reference for this would be good
|
|
||
| Layer 2 uses [`seccomp-bpf`][seccomp], which restricts the system calls that a process is allowed to send to the kernel. For example, applications generally do not need to communicate with device drivers via [`ioctl`][ioctl], especially webapps. Blocking this call removes a lot of attack surface, as an application could otherwise try to exploit a vulnerable driver to escape the sandbox. This idea is expanded to the entire list of system calls, only allowing the [bare minimum needed][least-privilege] to function. | ||
|
|
||
| These layers combined form a complete sandbox, restricting what a process can access using user namespaces, and restricting what it can do using `seccomp-bpf`. However, to create this sandbox, a process itself needs the privileges it's restricting, acting as a broker of permissions to its subprocesses. You cannot enforce the law without authority. This is where Flatpak, or really any attempt to sandbox a browser, begins to cause problems. It's essentially placing the broker, and all the sandboxes it makes, into one big sandbox. |
Contributor
There was a problem hiding this comment.
I'm adding this as a suggestion but this paragraph really doesn't belong in this section, everything but the first sentence belongs in the subsequent section.
Suggested change
| These layers combined form a complete sandbox, restricting what a process can access using user namespaces, and restricting what it can do using `seccomp-bpf`. However, to create this sandbox, a process itself needs the privileges it's restricting, acting as a broker of permissions to its subprocesses. You cannot enforce the law without authority. This is where Flatpak, or really any attempt to sandbox a browser, begins to cause problems. It's essentially placing the broker, and all the sandboxes it makes, into one big sandbox. | |
| These layers combined form a complete sandbox. However, to create this sandbox and act as a broker of permissions to its subprocesses, a process needs user namespace creation privileges. By restricting browsers from creation of user namespaces, Flatpak forces browser packagers to adopt workarounds. These workarounds essentially placing the broker, and all the sandboxes it makes, into one big sandbox. |
You cannot enforce the law without authority.
Removed editorializing/analogizing
begins to
This isn't something that's changing over time, it does cause problems, or it doesn't 😄
| ## [Overview](#overview) | ||
| {: #overview} | ||
|
|
||
| While we encourage Flatpak usage for general applications, this is *not* the case for web browsers. Currently, when compared to their native packages, they are incapable of reaching the same level of security within the Flatpak sandbox. This [could change in the future][flatpak-userns], but for the time being, we consider it safest to avoid them entirely. Instead, we encourage using other methods of installing a browser. We heavily recommend using Trivalent, and much of our efforts revolve around it, but we cannot stop users from installing another browser. |
Contributor
There was a problem hiding this comment.
Suggested change
| While we encourage Flatpak usage for general applications, this is *not* the case for web browsers. Currently, when compared to their native packages, they are incapable of reaching the same level of security within the Flatpak sandbox. This [could change in the future][flatpak-userns], but for the time being, we consider it safest to avoid them entirely. Instead, we encourage using other methods of installing a browser. We heavily recommend using Trivalent, and much of our efforts revolve around it, but we cannot stop users from installing another browser. | |
| While we encourage Flatpak usage for general applications, this is *not* the case for web browsers. Currently, when compared to their native packages, they are incapable of reaching the same level of security within the Flatpak sandbox. This [could change in the future][flatpak-userns], but until then Flatpaked browsers should be avoided entirely. |
Instead, we encourage using other methods of installing a browser.
Restatement of "avoid them entirely", which implies this
we cannot stop users from installing another browser.
Goes without saying, should be removed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I might start having flashbacks the next time I look at a physical sandbox. Closes #352