On Wed, Jul 8, 2026 at 8:32 AM Daniel P. Berrangé <[email protected]> wrote: > > On Wed, Jul 08, 2026 at 03:22:03PM +0200, Sebastian Wick wrote: > > On Wed, Jul 8, 2026 at 1:41 PM Daniel P. Berrangé <[email protected]> > > wrote: > > > > > > On Tue, Jul 07, 2026 at 09:09:18PM -0500, Michael Cronenworth wrote: > > > > On 7/7/26 9:23 AM, Aaron Rainbolt wrote: > > > > > This does not work. Someone did*exactly* this and I was able to > > > > > leverage it to escape sandboxes (vuln report is under embargo at the > > > > > moment). When you use a binfmt-misc handler, then when the sandboxed > > > > > executable tries to run the program, the kernel runs it*in* the > > > > > sandbox. When you use a MIME handler that gates access on the > > > > > executable bit, where the handler executes outside of the sandbox, > > > > > then when the sandboxed executable calls the MIME handler on a > > > > > marked-executable file, the file runs outside of (and thus escapes) > > > > > the sandbox. > > > > > > > > Fedora double-dips. We register both as a binfmt-misc handler (only > > > > when you > > > > have wine-systemd installed) and via the upstream .desktop files. > > > > > > > > I'm watching this thread but I don't have any suggestions at this time. > > > > My > > > > first impression is why does Flatpak change namespace/scope when > > > > performing > > > > MIME operations, but I don't know enough about the architecture to know > > > > why. > > > > > > Is the solution not a matter of making the binfmt-misc handler always > > > be installed by the core wine RPM, and droppping the .desktop file ? > > > > Correct! > > > > > Upstream quite reasonably wants to use a .desktop file because that > > > offers greater platform portability. The secrity scenario with flatpaks > > > sandboxing is only a Linux problem (at least right now). Portability > > > > Let's not get too focused on flatpak. The entire argument from CS > > Sushi Man is also that this is all the fault of Flatpak/Portals > > because it assumes something is safe that never was safe. > > IMHO the problem with Flatpak is that the OpenURI portal is an > inherantly dangerous concept. Even if the mime handlers are > correctly registered, it is still providing a way to pass a > potentially untrusted document and load it with a process that > is not itself sandboxed. Most document viewers have a long tail > of bugs which would be considered security issues in the context > of the flatpak portal OpenURI mechanism. > > It is understandable why it all works this way, because Flatpak > has to make a tradeoff to have a practical solution in the real > world given the historical baggage. Relying on strict compliance > with the xdg mime spec is an expediant approach but with totally > forseeable risks. Long term it appears inescapable that every > URI opener needs to itself run inside a separate sandbox to mitigate > this danger to Flatpak sandboxing, but I assume that's a very > challlenging thing to achieve in practice.
It depends on the context. If every URI opener was itself installed as a Flatpak, you would get this "for free". Sandboxing things that are installed as part of the OS outside of Flatpak for the sake of protecting a URI opener is a different kettle of fish; there are projects that try to do this like Firejail and Bubblejail, but those approaches are inherently fragile since they have to know how a particular binary of some application works in order to give it access to all the right resources. Only now, the binary is provided by a third party (the distro) that the sandbox developer has no control over, so the system is liable to break without warning the next time the distro uploads a package. Not to mention the fact that users generally expect the unsandboxed apps they've installed to have full access to everything, and may be very confused if an "unsandboxed" app launches in a sandbox. -- Aaron > With regards, > Daniel > -- > |: https://berrange.com ~~ https://hachyderm.io/@berrange :| > |: https://libvirt.org ~~ https://entangle-photo.org :| > |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :| > -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
