[Bug 59767] New: loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations
http://bugs.winehq.org/show_bug.cgi?id=59767 Bug ID: 59767 Summary: loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations Product: Wine Version: 11.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: loader Assignee: wine-bugs@list.winehq.org Reporter: arraybolt3@gmail.com Distribution: --- This is kind of a weird bug as it doesn't have anything to do with Windows applications in particular, but rather with how Wine registers itself with the system. loader/wine.desktop registers Wine as a MIME handler for a number of different Windows-related executable file formats (EXEs, MSIs, and Batch files. Linux doesn't recognize these files as programs (unless they have their executable bit set and are registered with binfmt-misc of course), so it will attempt to "open" these files with Wine. Wine will then run arbitrary code within these programs with the privileges of whatever program launched Wine. On the surface, this doesn't sound like a problem, but it becomes an issue because sandboxed code under Linux can usually use D-Bus to open files in their default application *outside of the sandbox*. Since the default application to open EXE files in is Wine, anything that can open arbitrary files outside of the sandbox can now escape the sandbox by writing an EXE file somewhere and then "opening" it with Wine. There are two ways I know of to do this: * Some file managers handle the org.freedesktop.FileManager1.ShowFolders method call by opening the "folders" they are told to open with their default application. Of course, there is no guarantee that the "folders" actually are folders; if the sandboxed app passes a file name in this call, those file managers will open the specified files in their default application. If Wine is installed, and one of the "folders" specified is an EXE file, the application can now run arbitrary code outside of the sandbox. (I reported this bug to an affected file manager over 90 days ago.) * xdg-desktop-portal-gtk intentionally allows applications to open arbitrary files outside of a sandbox, via the org.freedesktop.portal.OpenURI.OpenFile D-Bus method. If there are multiple applications that can open the same file type, it will usually open a dialog asking what application to open the file in, but if there is only one handler for a file type on the system, it will immediately open the file with its default handler. Handlers for EXE files other than Wine are relatively rare (lxqt-archiver is one, oddly enough), so there is a very good chance that a sandboxed app can just write an EXE file to the disk, then open it with xdg-desktop-portal-gtk and have code execution outside the sandbox. (I reported this privately to the Flatpak developers over 90 days ago.) Arguably, neither of these issues are security vulnerabilities in xdg-desktop-portal or file managers. The `xdg-mime` manpage warns: Security Note: Never set a handler that will blindly execute code or commands from the file being handled. Such behavior will sooner than later lead to unintended code execution i.e. through a curious user trying to inspect a freshly downloaded file but running it by accident. Keeping opening and executing separate actions helps with people protecting themselves from malware, the default handler is an opener, not a runner. Therefore I believe this is an issue with Wine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #1 from Hans Leidekker <hans@meelstraat.net> --- (In reply to Aaron Rainbolt from comment #0)
Arguably, neither of these issues are security vulnerabilities in xdg-desktop-portal or file managers. The `xdg-mime` manpage warns:
Security Note: Never set a handler that will blindly execute code or commands from the file being handled. Such behavior will sooner than later lead to unintended code execution i.e. through a curious user trying to inspect a freshly downloaded file but running it by accident.
Keeping opening and executing separate actions helps with people protecting themselves from malware, the default handler is an opener, not a runner.
Therefore I believe this is an issue with Wine.
Wine is a runner and users have come to expect that double-clicking a .exe launches the executable. Removing the handler registration would break that. It may be up to the packager to disable the registration when installed in a sandbox. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #2 from Aaron Rainbolt <arraybolt3@gmail.com> --- Disabling registration when installed in a sandbox doesn't help / isn't possible. In this scenario, Wine is installed unsandboxed on the host (which is the typical way one gets Wine if installing it from the winehq repos). The handler is registered on the host, and the handler is detected and triggered by an unsandboxed process (xdg-desktop-portal-gtk), so the handler would have to be unregistered on the host, something a sandboxed process obviously cannot do if everything is working right. Maybe instead of removing the handler, a prompt could be put in place so that users have to say "yes, I really do want to execute this" before code execution begins? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #3 from Hans Leidekker <hans@meelstraat.net> --- (In reply to Aaron Rainbolt from comment #2)
Disabling registration when installed in a sandbox doesn't help / isn't possible. In this scenario, Wine is installed unsandboxed on the host (which is the typical way one gets Wine if installing it from the winehq repos).
I don't mean Wine but whatever app (desktop environment?) is installed in the sandbox. If you don't want it to be able to automatically execute programs outside the of sandbox that mechanism should be disabled. There may be other launchers (emulators) that could be used in the same way.
Maybe instead of removing the handler, a prompt could be put in place so that users have to say "yes, I really do want to execute this" before code execution begins?
This is the responsibility of the process that invokes Wine (or any other app that executes a file). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #4 from Aaron Rainbolt <arraybolt3@gmail.com> ---
I don't mean Wine but whatever app (desktop environment?) is installed in the sandbox. If you don't want it to be able to automatically execute programs outside the of sandbox that mechanism should be disabled. There may be other launchers (emulators) that could be used in the same way.
I think we may be having a misunderstanding about how Linux app sandboxing mechanisms work. Both Flatpak and Snap assume that opening a file and executing a file are two different things. This assumption is warranted, because the mechanism that handles file associations under Linux (xdg-mime) explicitly documents that opening and executing are two different things and that file openers should never blindly execute code. Both Flatpak and Snap allow a sandboxed application to say "open this file with whatever its default file handler is", which will either launch an app in a different sandbox, or launch an unsandboxed app. xdg-desktop-portal-gtk then finds a file handler for the file its been given, and runs it, pointing it at the file. In the context of Wine, that file handler happens to execute arbitrary code. There isn't anything in the pipeline that knows it's about to execute code, except for Wine. That's why I suggested adding a prompt to Wine itself. There isn't any such thing as "disabling" this. One would have to either disable access to xdg-desktop-portal-gtk entirely (which is impossible with the current design of Flatpak from what I understand and would severely break applications if it was done in general), or they would have to remove the Wine EXE file association from the system entirely. There isn't any way to say "ignore this particular file association because it executes code". Even if there was a way to ignore a specific file association, it would be unreasonable to make sandbox designers use it, since that would require maintaining a blacklist of known-unsafe file handlers, and there's no good way to find every application that registers an unsafe handler. According to the docs, unsafe handlers shouldn't exist at all.
This is the responsibility of the process that invokes Wine (or any other app that executes a file).
Only if the process that executes a file knows that it is going to execute a file. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 Olivier F. R. Dierick <o.dierick@piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be --- Comment #5 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- Hello. It's not an issue with WINE, because you can associate EXE files (or any other executable file format, including scripts) with anything other than WINE and the issue remains the same. Your issue is more generic and the cause lies in the way the sandbox handles associations. (In reply to Aaron Rainbolt from comment #4)
Both Flatpak and Snap allow a sandboxed application to say "open this file with whatever its default file handler is", which will either launch an app in a different sandbox, or launch an unsandboxed app.
That is the issue. Flatpak and Snap are not true sandbox if they let the app run code outside of the sandbox. If you want your sandboxed app to not be allowed to run executable files outside of the sandbox, then use a sandbox that doesn't allow that. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #6 from Aaron Rainbolt <arraybolt3@gmail.com> ---
That is the issue. Flatpak and Snap are not true sandbox if they let the app run code outside of the sandbox.
That depends on the kind of code though. If a user downloads a Word document with a sandboxed Firefox, then clicks the "Open" button in the browser to open it, the user would naturally expect that a) the file should open, and b) opening the file won't run arbitrary code within the file. To open the file, the sandboxed browser needs to either bundle an office suite within its own sandbox (which is unrealistic for per-app sandbox systems like Flatpak), or it needs to tell something outside the sandbox to open the file. That "something" is xdg-desktop-portal-gtk, and the way it determines how to open the file is by MIME handlers. This is a safe operation if the documentation that says "never register a MIME handler that blindly runs code from a file" is followed, it's an unsafe operation otherwise. I don't see how Wine doing something the documentation explicitly says to not do makes Flatpak "not a true sandbox". If there was a way to register MIME handlers with a warning on them that says "this will run arbitrary code", then I would agree with you, but there is a mechanism like that already, binfmt-misc. If that was used instead of MIME, it would allow people to double-click EXE files in their file manager and run them, while also not allowing a sandboxed app to break out. By using MIME, Wine is telling the system "Hi, I can open EXE files without running them", when in reality it does run them. binfmt-misc would let Wine say "Hi, I can open EXE files, but I will run them in the process", which is more in line with what Wine actually does. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #7 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- Hello, That's design and software architecture discussion and highly debatable. There is no bug in Wine. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 Olivier F. R. Dierick <o.dierick@piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |enhancement -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #8 from Aaron Rainbolt <arraybolt3@gmail.com> --- Do you propose a better way for offering a file handler registration mechanism that is explicitly for non-executable file types, whereby any application that registers an executable file type with it can be considered buggy? It's very hard for me to understand how "there is no bug in Wine" when Wine is using a mechanism in the exact way the mechanism documents should never be done. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 Zeb Figura <z.figura12@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com --- Comment #9 from Zeb Figura <z.figura12@gmail.com> --- (In reply to Aaron Rainbolt from comment #6)
That depends on the kind of code though. If a user downloads a Word document with a sandboxed Firefox, then clicks the "Open" button in the browser to open it, the user would naturally expect that a) the file should open, and b) opening the file won't run arbitrary code within the file.
I don't see how that has anything to do with sandboxing, though? The system isn't designed with any way to know whether something is trustworthy or not, so something like LibreOffice can't make that decision based on the presence of a sandbox; it has to decide to not do anything dangerous for *any* files, ever. Generally, then, an application has to decide whether it is going to act as a security boundary, or whether it's going to put all the burden of trust on the user. LibreOffice can act as a security boundary relatively easily (as I understand). Firefox has a harder time, but chose to do it anyway. Wine has *always* decided not to, mostly because it has an extremely hard time doing so. Once you're letting code run natively on the processor, it is very hard to prevent it from escaping, and attempts to do so very frequently come with a performance cost, not to mention a development cost. Wine's behaviour may contradict XDG guidelines, but there's no way to follow them while still being useful. As far as I can tell, the implicit assertion behind the guidelines is "users shouldn't have to vet the files they're opening", which is incompatible with Wine's security model. It would make more sense to argue that Wine should be a sandbox. I don't expect that argument to be well-received, though, and you should be prepared to be able to put up all of the work that would be necessary, since nobody else is likely to, whether volunteer or sponsored. Also, how exactly does Flatpak deal with ELF binaries? They're in essentially the same category. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #10 from Aaron Rainbolt <arraybolt3@gmail.com> ---
I don't see how that has anything to do with sandboxing, though? The system isn't designed with any way to know whether something is trustworthy or not, so something like LibreOffice can't make that decision based on the presence of a sandbox; it has to decide to not do anything dangerous for *any* files, ever.
Generally, then, an application has to decide whether it is going to act as a security boundary, or whether it's going to put all the burden of trust on the user. LibreOffice can act as a security boundary relatively easily (as I understand). Firefox has a harder time, but chose to do it anyway. Wine has *always* decided not to, mostly because it has an extremely hard time doing so. Once you're letting code run natively on the processor, it is very hard to prevent it from escaping, and attempts to do so very frequently come with a performance cost, not to mention a development cost.
I agree with you that Wine *should* not act as a security boundary. Unfortunately, that's exactly what it is doing; by registering itself as a MIME handler, Wine is telling the system "I am capable of acting as a security boundary. If you hand me an EXE file, I can do something the user finds useful with it, without compromising the system." That's what the MIME handler system is for. Of course, Wine isn't capable of keeping that promise, for the reasons you described, which is why I'm arguing that Wine should not be promising the system that it will behave in a safe way. The reason I mentioned LibreOffice is because it's a good example of why sandboxed apps need to be able to make applications outside of their sandboxes open files. Sandboxing is intended to isolate apps, but apps are not used in isolation, so saying "just use a sandbox that doesn't allow opening files" doesn't work (at least not if you're looking at per-app sandboxing). The system needs to know what apps can safely open specific file types from untrusted sources, and the MIME database is its source of info for that.
Wine's behaviour may contradict XDG guidelines, but there's no way to follow them while still being useful.
There is though. As I mentioned above, the binfmt-misc system exists for the purpose of registering code interpreters / loaders with the kernel. If Wine were registered as a binfmt-misc handler for EXE files, users could then double-click EXEs that had their executable bit set, and they would run, very much like how they do now. At the same time, Wine would not be promising the system that it is a safe handler for EXE files, and so the system would not trust it to open arbitrary things a sandbox hands to it.
As far as I can tell, the implicit assertion behind the guidelines is "users shouldn't have to vet the files they're opening", which is incompatible with Wine's security model.
That is the implicit assertion in the manpage, but it isn't the focus of this report. The focus of this report is *users don't have control of the files they open.* If a user has Wine installed, any running application in any Flatpak (and probably many Snaps) can trivially escape the sandbox at will, without user interaction. I don't think users expect that installing Wine will break the security model of unrelated applications, even if the user doesn't do anything with Wine other than install it.
It would make more sense to argue that Wine should be a sandbox. I don't expect that argument to be well-received, though, and you should be prepared to be able to put up all of the work that would be necessary, since nobody else is likely to, whether volunteer or sponsored.
This isn't really related to the bug report. Wine itself doesn't really need to be sandboxed IMO (and there are projects already out there that sandbox it if you want).
Also, how exactly does Flatpak deal with ELF binaries? They're in essentially the same category.
ELF binaries don't have any MIME handler registered. They aren't generally "opened" in the traditional sense, they're exec'd. PE binaries can be exec'd on Linux too, but only if they are registered with the kernel using binfmt-misc. Because there isn't a MIME handler for ELF binaries, opening them with org.freedesktop.portal.OpenURI.OpenFile doesn't do anything useful to an attacker. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #11 from Zeb Figura <z.figura12@gmail.com> --- (In reply to Aaron Rainbolt from comment #10)
I agree with you that Wine *should* not act as a security boundary. Unfortunately, that's exactly what it is doing; by registering itself as a MIME handler, Wine is telling the system "I am capable of acting as a security boundary. If you hand me an EXE file, I can do something the user finds useful with it, without compromising the system." That's what the MIME handler system is for. Of course, Wine isn't capable of keeping that promise, for the reasons you described, which is why I'm arguing that Wine should not be promising the system that it will behave in a safe way.
Okay, I had a feeling that's where this might eventually lead; this position does make sense to me. I don't know why we ship a .desktop and not a binfmt_misc handler. Portability, maybe? It does feel like an oversight that xdg in itself doesn't provide this distinction and relies on other tools to do so (or, well, considers it out of scope? Still feels like an oversight)
That is the implicit assertion in the manpage, but it isn't the focus of this report. The focus of this report is *users don't have control of the files they open.* If a user has Wine installed, any running application in any Flatpak (and probably many Snaps) can trivially escape the sandbox at will, without user interaction. I don't think users expect that installing Wine will break the security model of unrelated applications, even if the user doesn't do anything with Wine other than install it.
Well, I'm not exactly sympathetic to this direct appeal, because I don't think you can argue that Flatpak is doing a reasonable thing here without being able to appeal to xdg-mime and the intent behind xdg-mime. Flatpak tends to do things I find unreasonable, after all... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #12 from Aaron Rainbolt <arraybolt3@gmail.com> --- Hmm, portability is a concern I hadn't thought of. It looks like BSDs in general don't support binfmt-misc or a similar mechanism. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 Olivier F. R. Dierick <o.dierick@piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |integration --- Comment #13 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- Hello, Wine doesn't register itself as the DEFAULT handler anywhere in the code. All Wine does is to install a few .desktop files in ~/.local/share/applications. The loader/wine.desktop file is not even there on my system. It's installed in "$INSTALL_DIR/share/applications", nowhere else, and 'xdg-mime query default <mimetype>' returns nothing for the concerned mimetypes. If it's different on your system, then it may come from the Wine package you installed. It probably copied the wine.desktop file into /usr/share/applications or the ~/.local equivalent. I'm not saying that it's wrong, though. My understanding of the XDG documentation is that setting the default handler is the responsibility of the user/system policy. However, XDG happily sets the default handler to the first handler if there is only one. The Freedesktop/MIME/XDG specifications provide no way for a .desktop file to indicate whether the handler is an opener or runner. Requiring that the default handler is an opener, but automatically setting the first one as the default without asking the user, and without anyway to tell openers from runners, is a broken implementation to me. XDG should either: - Not blindly set the first handler as the default handler; - Provide a mechanism to distinguish between openers and runners (and only use openers as default); If there is a bug somewhere, it's in the XDG implementation. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #14 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- Hello, I'm curious as to what makes you say that the "MIME handler system" promises a form of security boundary. Where did you get that notion from? To me, there is no security implied from that system. You can set anything as a MIME handler and there are no security checks of any kind. It's practically just a shortcut to launch an application from the files without opening it first and then loading the files. I might even say that it is a security vulnerability if the handlers are not examined before they become active. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #15 from Aaron Rainbolt <arraybolt3@gmail.com> ---
Wine doesn't register itself as the DEFAULT handler anywhere in the code. All Wine does is to install a few .desktop files in ~/.local/share/applications. The loader/wine.desktop file is not even there on my system. It's installed in $INSTALL_DIR/share/applications", nowhere else, and 'xdg-mime query default <mimetype>' returns nothing for the concerned mimetypes.
What happens if you try to 'xdg-open' an EXE file? On my end, this always automatically launches the application, on both Fedora (using WineHQ's RPM package) and Debian (using WineHQ's DEB package), if I'm remembering correctly. I've also seen "Wine Windows Program Loader" as an option in the "Open With..." menus of various file managers when right-clicking an EXE file, something that should only happen if the MIME system recognizes Wine as a file handler for EXE files. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #16 from Aaron Rainbolt <arraybolt3@gmail.com> ---
I'm curious as to what makes you say that the "MIME handler system" promises a form of security boundary. Where did you get that notion from?
The xdg-mime manpage quoted in the original report, which states clearly "Keeping opening and executing separate actions helps with people protecting themselves from malware, the default handler is an opener, not a runner." -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #17 from Olivier F. R. Dierick <o.dierick@piezo-forte.be> --- (In reply to Aaron Rainbolt from comment #15)
What happens if you try to 'xdg-open' an EXE file? On my end, this always automatically launches the application, on both Fedora (using WineHQ's RPM package) and Debian (using WineHQ's DEB package), if I'm remembering correctly. I've also seen "Wine Windows Program Loader" as an option in the "Open With..." menus of various file managers when right-clicking an EXE file, something that should only happen if the MIME system recognizes Wine as a file handler for EXE files.
Hello, I only use locally built Wine, no distributed package, that probably makes a difference. Gnome File Roller is the default handler for application/x-ms-dos-executable on Gnome/Debian. If I disable the File Roller handler, 'xdg-open' prints an error message 'Unable to find the default application for this type of content "application/x-ms-dos-executable"' (rough translation from French), and in nautilus it shows a "no application for this file" dialog. I made a few tests with stub desktop files and XDG selects the default in that order (first found becomes the default): - first desktop file specified in the user's mimeapps.list; - first desktop file specified in the system's mimeapps.list; - first desktop file in the user's database directory, in alphabetical order; - first desktop file in the system database directory, in alphabetical order; If you want to prevent Wine from running EXE files without confirmation, you could set the default handler to something else in your mimeapps.list, a desktop file for a custom wrapper script, for example. (In reply to Aaron Rainbolt from comment #16)
The xdg-mime manpage quoted in the original report, which states clearly "Keeping opening and executing separate actions helps with people protecting themselves from malware, the default handler is an opener, not a runner."
That's a security policy. There is no concrete mechanism to enforce it in the implementation. Wine cannot prevent XDG to select it as the default handler, since XDG just uses the first desktop file it finds. Having some way to tell XDG that a handler is not an 'opener' but a 'runner', and enforcing the policy by excluding runners from being selected as default, is a valid feature request to direct at Freedesktop. If they offered such a feature, Wine would use it. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #18 from Hans Leidekker <hans@meelstraat.net> --- (In reply to Aaron Rainbolt from comment #16)
I'm curious as to what makes you say that the "MIME handler system" promises a form of security boundary. Where did you get that notion from?
The xdg-mime manpage quoted in the original report, which states clearly "Keeping opening and executing separate actions helps with people protecting themselves from malware, the default handler is an opener, not a runner."
To put this into perspective, this message was added in 2023 while tools/wine.desktop with the application/x-ms-dos-executable MIME type was introduced in 2004. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 mata <sutupud@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sutupud@yahoo.com --- Comment #19 from mata <sutupud@yahoo.com> --- xdg-open behaves differently based on which current desktop is running. For example, with KDE on arch I get: xdg-open /usr/lib/wine/x86_64-windows/winemine.exe For security reasons, launching executables is not allowed in this context. But if I force the flatpak behavior: gdbus call --session \ --dest org.freedesktop.portal.Desktop \ --object-path /org/freedesktop/portal/desktop \ --method org.freedesktop.portal.OpenURI.OpenFile \ --timeout 5 \ "" "3" {} 3< /usr/lib/wine/x86_64-windows/winemine.exe then the program is opened. The arch package basically does effectively the same as installing with, make prefix=/usr ... install so it does end up with wine.desktop in /usr/share/applications. The packages from dl.winehq.org don't, since they install to /opt/wine-devel or similar. Probably it's not the ony distribution that does that. But at least looking over at debian, according to https://packages.debian.org/trixie/all/wine/filelist the file is put into /usr/share/doc/wine/examples/wine.desktop instead. for `xdg-mime query ...` I get application/vnd.microsoft.portable-executabl, which seems to be a subclass of application/x-msdownload, which has as alias application/x-msdos-executable, so therfore wine.destop is selected. If I remove this file, I get a "choose application to open this file..." when running the dbus command. Looking through the installed .desktop files, I can find at least one other file that could also be used the same way - https://gitlab.archlinux.org/archlinux/packaging/packages/java-openjdk/-/blo... has: Exec=/usr/lib/jvm/java-26-openjdk/bin/java -jar MimeType=application/x-java-archive;application/java-archive;application/x-jar; That would also classify as runner, not as opener. But here there's also a second application that claims the same mime type, org.kde.ark.desktop, which prevents the automatic opening and causes the selection dialog to be shown. Without the org.kde.ark.desktop file, jars will be automatically executed. Lastly, the security note on xdg-mime advises to not set a runner as *default*, not against having runnes present in the first place. It's also prominently placed on the `xdg-mime default ...` sub-command. So it could be argued that since it can't be known if something is a runner or opener, choosing any application as default without it actually being explicitly set as default goes against that advice. But it's the portal which is doing that. "the default handler is an opener, not a runner" sounds strange in that context. Maybe it *should be* an opener, but there is no telling whether it is or not. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #20 from Hans Leidekker <hans@meelstraat.net> --- (In reply to mata from comment #19)
Lastly, the security note on xdg-mime advises to not set a runner as *default*, not against having runnes present in the first place. It's also prominently placed on the `xdg-mime default ...` sub-command. So it could be argued that since it can't be known if something is a runner or opener, choosing any application as default without it actually being explicitly set as default goes against that advice. But it's the portal which is doing that.
"the default handler is an opener, not a runner" sounds strange in that context. Maybe it *should be* an opener, but there is no telling whether it is or not.
It sounds to me like the default handler setting is being overloaded to provide safety against automatically invoking runners. It be nice if a mechanism could added instead. An extra property that specifies whether the handler is a runner or an opener and a way to request either or both. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #21 from Aaron Rainbolt <arraybolt3@gmail.com> --- I think I probably need to look at how MIME handling works in general more closely. I see there is a good reason to have executable MIME handlers since binfmt-misc is Linux-specific and not supported elsewhere. I like the idea of "don't have defaults that aren't explicitly specified" in general, but users might still not expect that explicitly opening a program with "Wine Windows Program Loader" will cause code execution, even if they get an "Open With..." prompt. I also like the idea of being able to say clearly whether a handler opens or executes a file, but am not sure how practical that is. It kind of feels like the MIME system itself is subtly broken here, at least now that we live in a world where app-specific sandboxing is a thing. There's a parallel discussion about these issues on the oss-security mailing list that I started after originally filing this report: https://www.openwall.com/lists/oss-security/2026/05/19/1 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 Austin English <austinenglish@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #22 from Aaron Rainbolt <arraybolt3@gmail.com> --- I submitted a proposed spec change for the desktop file specification to FreeDesktop: https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/116 Ultimately, it looks very likely to be rejected, because upstream believes very firmly that the MIME handler system should never have been used for registering things that execute files by proxy (like Wine). "Executable MIME handlers" can result in users unintentionally running malicious code by not understanding that opening a file with a program will run code, and can bypass system restrictions on what a user is allowed to run (among other things). On Linux, binfmt-misc should be used instead of the MIME handler, while on BSDs or other systems without a binfmt-misc-like mechanism, the MIME handler should be removed without replacement. Even if Wine does not agree with this entirely and wants to keep using a MIME handler on BSDs and the like, can Wine at least use binfmt-misc on Linux instead of the MIME handler? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla