Wine is now good enough to run viruses, but not good enough to run antivirus software. Running anything under Wine is a security risk. It would be great if Wine could be sandboxed by default using systemd Lightweight Containers. I ran into this issue last night -- I was doing some forensics on the Destover malware that wiped Sony's desktop machines. Since I was running on Fedora and had no intention whatsoever of running the malware (yet still foolishly), I was not examining the files in a sandbox or VM. Somehow I managed to actually execute the malware in Wine without realizing (I don't even know how, I think I accidentally double-clicked on a file rather than single-clicked on it). Ten minutes later, the malware's delayed attack timer went off and it started deleting all files on my Fedora hard drive. I only noticed after several thousand files had been deleted, and I hard-powered-off the machine, but the damage was already done. I filed Bug 625979 several years ago asking if ClamAV could be configured by default in Linux to scan Windows executables before running them. But systemd Lightweight Containers would be a great way to contain runaway code, given that most Linux users that use Wine only use it to run one or two programs on an occasional basis. A user could be ask when launching a Wine application which directories they would like to make visible inside the container, and mapped to what Windows drive. They should also be shown a warning that Windows binaries are not protected against malware in Linux, and that the malware could access the mapped drive, the network device, etc.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Hi, I would like to reopen this bug now that there are a number of lightweight container options available, including systemd containers, flatpak, and firejail. Wine is very insecure out of the box, because there is so much compromised Windows software floating around in the wild. Windows viruses now run scarily well on Windows, as evidenced by my own experience (described in the original bug report), where a Windows virus proceeded to wipe my Linux hard drive. Can Fedora please protect Wine users using one of these new containerization mechanisms? Firejail already has a Wine profile in its default installation, but I don't know how good the protection of the filesystem is out of the box, and requiring a user to manually whitelist and blacklist directories is not a great idea. It would be nice to put in place the xdg-desktop-portal system for Wine, and force Wine to run inside a flatpak container.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
Hi all. I agree with author of this issue. WineHQ is very dangerous if used without sandbox mechanism. Moreover, the flatpak package of it's derivative (the so called "Phoenicis PlayOnLinux") is not sandbox in secure way (there is holes in their flatpak sandbox!) - see: https://www.flathub.org/apps/details/org.phoenicis.playonlinux https://github.com/flathub/flathub/issues/960 My user name at GitHub is Nokia808 & I'm who opened above issue (question) about safety of use Phoenicis. So, what we need indeed is official Fedora default sandbox mechanism (protection layer) for WineHQ package that already existing in official Fedora repositories .....
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening again.
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
Nothing to do here on the flatpak side.
@David King Why no thing could be done from flatpak side ?! The flatpak has currently sandbox with very strong permissions options that can be customized to be very strong so that when supposed winehq flatpak run a virus or other malware, then such dirty program (virus or other malware) will not produce a harmful effects because it will be (& that is what should be) sandbox ...... This way, flatpak can replace "run winehq through virtual machine" & being safe in similar way to that of virtual machine .... If you mean that flatpak can not due something because merely WineHQ is a command line program without front end, then we should explained that no one here asking to make WineHQ as independent flatpak package at all ! No ! WineHQ when packaged as flatpak should be in the form of a "run time" that could be used by other GUI flatpak packages like Q4Wine. I will take Q4Wine as example: 1) Q4Wine is a GUI for WineHQ - see: https://q4wine.brezblock.org.ua/ https://github.com/brezerk/q4wine/tree/master 2) Q4Wine is designated to use WineHQ as a dependency for it - see: https://github.com/brezerk/q4wine/issues/102 3) Q4Wine is already existing in official Fedora repositories. When you try to install it by "sudo dnf install q4wine", then DNF will ask you to install WineHQ as dependencies. 4) so you can make both Q4Wine & WineHQ packaged as a flatpak packages, so that when user installed Q4Wine, then it will ask to install WineHQ as a "run time" for it. This way should WineHQ shipped as flatpak. There are, also, other benefits from shipping WineHQ as flatpak: - WineHQ need many X32 bit packages, & at these days most of Linux OS that installed are X64 bit. So it will be better if such X32 bit packages installed in isolated way (I mean sandbox) from packages of OS. - WineHQ installation as .rpm/.deb format will ask for huge download size that will be RE-DOWNLOADED EVERY TIME RECEIVING NEW UPDATE OR DURING PROCESS OF SYSTEM UPGRADE. This will bear a heavy weight specially when Internet speed is slow. This is specifically dangerous during system upgrade in such state when every increase in total download size curry additional risk of system upgrade process failure ..... Kindly, re-consider.
(In reply to yousifjkadom from comment #11) The important point is that none of what you ask for can be done inside the flatpak package in Fedora. If you think that the wine package in Fedora should provide some kind of flatpak environment around wine, this could be the right place to ask. The wine maintainer would probably know the answer, which is why this bug is assigned to wine, not flatpak.
I agree, this is a request for changes to the Fedora distribution of Wine, not to Flatpak. And Flatpak is only one of several possible sandboxing mechanisms that could be used to make Wine safer, as I pointed out in the original request. Should this request be made to upstream Wine, rather than Fedora? Does RedHat have any engineers who actively work on Wine?
Hello everyone. > Should this request be made to upstream Wine, rather than Fedora? Does RedHat have any engineers who actively work on Wine? I've made not so long ago some Wine upstream discussion related to Wine <-> Flatpak, but it was more Flathub related and in same time in fact not really about Flathub. It's more about symbiosis of Wine and Flatpak so maybe we can also continue discussing this upstream https://forum.winehq.org/viewtopic.php?f=8&t=34721
It seem that I did not understood what author was asking when he mentioned flatpak ! If he asked to make flatpak providing sandbox for .rpm package then definitely wrong & @David King was correct when he said "no thing to be done from flatpak side" ! Flatpak can not do this at all ! It is providing sandbox for flatpak packages from system not for .rpm/.deb package from system. For sandbox .rpm/.deb package, Currently, there is available in official Fedora repositories called firejail can perform this very well. All what I have to say, now, is why Fedora - which is SELinux based distro - not providing SELinux profile for WineHQ ?? It provides SELinux profile for flatpak & for snap. When you install flatpak "sudo dnf install flatpak" there will be SELinux profile as a dependency will be downloaded. Same with snap. So, why there is, currently, no SELinux profile for WineHQ ?? This is taking additional value if we taking in mind that firejail fully compatible with SELinux, so that user can activate firejail WineHQ profile & this will be added to WineHQ SELinux profile. Such union will achieve good protection ......
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.