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. 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
