Figure out how to chroot/use namespace isolation in flatpak
Categories
(Core :: Security: Process Sandboxing, enhancement, P3)
Tracking
()
People
(Reporter: emersonbernier, Unassigned)
References
Details
Steps to reproduce:
Flatpak firefox internal sandbox isn't effective due to lack of direct User Namespaces access. Open about:support in firefox flatpak app, then navigate to Sandbox section.
Actual results:
User Namespaces are set to false which means most parts of internal sandboxing are disabled.
Expected results:
Some workaround for lack of user namespaces should be considered. Chromium for example uses zypak project which may be used for inspiration: https://github.com/refi64/zypak
|
Reporter | |
Updated•2 years ago
|
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Security: Process Sandboxing' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•2 years ago
•
|
||
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.
|
|
Reporter | |
Comment 3•2 years ago
|
||
(In reply to Gian-Carlo Pascutto [:gcp] from comment #2)
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.
I had a chat with mozila dev on #flatpaks irc channel and I was told that without user namespaces only seccomp part of sandbox is still active. It could be that seccomp stands for most of the existing sandbox alone, I don't know. They also suggested ff could use flatpak-spawn like webkit does: https://github.com/WebKit/WebKit/blob/main/Source/WebKit/UIProcess/Launcher/glib/FlatpakLauncher.cpp#L36
BTW: after latest debian release enabled user namespaces by default there is no major linux distro which disables them.
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.
To my knowledge there are two techniques for self-sandboxing apps under linux: user namespaces and setuid root helpers. Neither of chromium or flatpak sandboxes would exist without one those. If ff can't access both then how it creates its sandbox, i.e. how it's limiting file, network and other resource access per process?
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.
I meant if there is not much sandbox without user namespaces then there's not much to bypass as resources are freely available. I admit I may be wrong due to lack of understanding inner workings of ff sandbox. The wiki says ff "Uses Unprivileged User Namespaces (if available)" but for what exactly namespaces are used for?
|
|
||
Comment 4•2 years ago
•
|
||
If ff can't access both then how it creates its sandbox, i.e. how it's limiting file, network and other resource access per process?
We intercept the syscalls via seccomp-bpf.
The wiki says ff "Uses Unprivileged User Namespaces (if available)" but for what exactly namespaces are used for?
chrooting (which would require a setuid binary otherwise), and also IPC and network isolation for processes where that is possible. Because of the above, it's defense in depth. (I think there's also experimental patches for PID isolation, somewhere...)
BTW: after latest debian release enabled user namespaces by default there is no major linux distro which disables them.
Ah, that's cool. Arch (and derivatives) is/was another holdout.
|
|
||
Comment 5•2 years ago
•
|
||
They also suggested ff could use flatpak-spawn like webkit does
Right now we just fork(), so replacing that with flatpak-spawn would cause a massive increase in memory usage? You would no longer have CoW sharing of memory. I suspect this only deals with launching the main process (or WebKit would have the same memory usage problem?), and it's not clear to me the "Flatpak Sandbox" it's creating is comparable to what we have now (even with just seccomp-bpf). We launch our subprocesses with specific, nailed down sandboxes. So I'm not clear that gets us closer to where we want to be.
|
|
Reporter | |
Comment 6•2 years ago
|
||
(In reply to Gian-Carlo Pascutto [:gcp] from comment #4)
chrooting (which would require a setuid binary otherwise), and also IPC and network isolation for processes where that is possible. Because of the above, it's defense in depth. (I think there's also experimental patches for PID isolation, somewhere...)
For me it sounds important.
Ah, that's cool. Arch (and derivatives) is/was another holdout.
Main Arch kernel enabled user namespaces long time ago. There is optional linux-hardened flavor which still disables them but it's rather niche dedicated for sophisticated users.
(In reply to Gian-Carlo Pascutto [:gcp] from comment #5)
Right now we just fork(), so replacing that with flatpak-spawn would cause a massive increase in memory usage? You would no longer have CoW sharing of memory. I suspect this only deals with launching the main process (or WebKit would have the same memory usage problem?), and it's not clear to me the "Flatpak Sandbox" it's creating is comparable to what we have now (even with just seccomp-bpf). We launch our subprocesses with specific, nailed down sandboxes. So I'm not clear that gets us closer to where we want to be.
The goal is to replicate missing sandbox features within flatpak rather than replace whole ff sandbox. Flatpak allows to spawn subprocesses with more restricted sandboxes than otiginal one without direct access to user namespaces through flatpak-spawn.
Here's patch from chromium which transforms native, namespaces based sandbox to flatpak-spawn:
https://github.com/flathub/org.chromium.Chromium/blob/master/patches/chromium/flatpak-Add-initial-sandbox-support.patch
|
|
||
Comment 7•2 years ago
|
||
Main Arch kernel enabled user namespaces long time ago.
Ah, great. I'm happy we held out on shipping the setuid root solution then :-)
Flatpak allows to spawn subprocesses ...through flatpak-spawn.
Yes, but as explained above, flatpak-spawn is not fork() so this would cause a massive increase in Firefox memory usage. Unlike the WebKit patch, the Chromium patches are much closer to our level of sandboxing and kind of illustrate this, from skimming it (so this might be entirely wrong) Chromium works around this by first spawning an intermediate (zygote) process with flatpak-spawn to get the right isolation and then fork()-ing off of that. Our equivalent of that would be finishing bug 1609882 and then finding some way to deal with the various sandbox levels we have (which are a bit more fine grained than Chromium, for some processes, IIRC).
Alternatively, you could hack up the WebKit method and accept the memory usage regressions. (Don't think we'd want to go that route for a default build)
Description
•