AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Brave browser github11/22/2023 ![]() Again: I haven't yet learned the details of how this API works and I haven't verified the claims, it seemed legitimate.Īs a result, there is a seemingly active collaboration between the Flatpak team and the Snap team (the other major player) to agree on a common high-level API that could be used in a new patchset to be presented again to the Chromium team (and leveraged by all other application vendors who need "granular sub-sandboxing"). I gathered that a patch to Chromium was submitted which leveraged this, but it was rejected given how specific it is to Flatpak, though apparently the Chromium team expressed they'd reconsider if Flatpak were to become more dominant. However, Flatpak and similar systems block this for security reasons (I haven't researched the details yet but given this is widespread and seemingly well discussed upstream it seems legitimate and not an oversight).įlatpak offers a higher-level API to allow sandboxed applications to run sub-processes in nested sandboxes in a secure way see flatpak-spawn. I've confirmed nested user namespaces are fully supported by the kernel, and that since 3.8 unprivileged processes can create them. (I haven't validated both these claims thoroughly but I'm somewhat confident it's accurate.) So, in other words: while using -no-sandbox would protect the host from Brave, internal Brave subcomponents wouldn't be protected from each other and this is why Chromium sandboxing is still desirable. Yet, Chromium sandboxing isolates some of its subsystems and tabs from each other, and as such requires nested user namespaces. Now, AFAICT Flatpak would already isolate the full application in a single user namespace, even when -no-sandbox is passed to Chromium (this is independent from contained processes). User namespaces sandbox Enabled by default (modern kernels) and actively developedĬhromium 43 was released in 2015 and Linux 3.10 in 2013. Setuid sandbox Enabled by default (old kernels) and maintained Starting with M-44, certain processes run in their own PID namespace, which isolates them better. Starting with M-43, if the kernel supports it, unprivileged namespaces are used instead of the setuid sandbox. It generally requires a kernel >= 3.10, although it may work with 3.8 if certain patches are backported. It's based on (unprivileged) user namespaces in the Linux kernel. It has the advantage of not requiring a setuid binary. The namespace sandbox aims to replace the setuid sandbox. I don't know the full set of trade-offs between these methods yet, but that is something I am investigating before this goes live. But I know there are other methods like saying // if we only wanted one listing. With a secondary for the development channel. Then when stable comes, transition that to being stable-only builds. What I'd like to do is have be what we install now since all we have is dev builds. I'm going to have a conversation on how to handle this with other Flathub maintainers. Overall pretty straightforward, but the more complex issue to figure out before releasing it is how to handle versioning. Copy in the logo and setup a desktop file to run the program and allow it into the system for setting it as a default web browser. So what I did for my initial builds, which I will repeat again here with the initial containers, is simply pull the generic build into an image. The site currently still links to the old laptop instructions and not the new docs (which conveniently also is missing the generic instructions anyways.) OK so the new generic linux builds are available on the releases page for this repo.
0 Comments
Read More
Leave a Reply. |