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.