Peter Andersson a écrit:
Hello again,
(FYI, I took the liberty to change the topic since I started the former thread "How is Win/Dos syscalls implemented in Wine?" which I feel has gone a little bit off-topic)
I had some more thoughts on the issue...
I believe most wine users trust wine not to touch anything outside of its configured drive space.
"Trust" might be a bit too heavy. "Believe" would be more appropriate. Running Wine is (and has always been) a bit of a security risk, the same way (although to a lesser extent) than say SUID libsvga apps. That's why, if you think the risks exceed what you are ready to bear, then don't use it on your systems.
Malicious Linux/Unix syscalls could be embedded in windows apps and if executed do a great deal of damage.
The same way they can be embedded in any Linux native trojan.
After all checking your app is run whithin Wine is not that hard (reading registry settings for instance). Lets call such an malicious app a wine-virus from now on. At present a wine-virus would even be allowed to fork itself, leaving the wine environment and continue to run even after you shutdown the wineserver, and in some cases even after the user logs out. The virus would now have full access to the system whithin the users permission, doing much greater damage than you expected.
It doesn't have any more permission than any other closed-source app you run on your system. Are you that sure that, let's say, UT2K3 (or any other closed-source or even open-sourec native Linux app) won't try to do that, either maliciously or by accident?
The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows?
How do you know it _is_ safe to run in Windows? Because you never had a problem running it? Hardly a proof, no?
In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt.
No need for convulated interrupt calling. Just call (through system()) something along the lines of "/bin/sh -c /bin/rm -rf /" (beware, don't actually *do* that!) to get that effect. Since the deletion is done through /bin/rm rather than a Wine (or your app) libc call, then anything you add to protect from this in Wine won't help.
"Then don't allow Win32 apps to run Unix apps."
Ok. Then include a Winelib app which will call that Unix app. You *do* want us to allow the calling of Winelib apps, don't you? Else, you wouldn't be able to run notepad.exe.so from an installer to see the release notes.
And since a Winelib app is a native Unix app, adding something to Wine wouldn't help.
I really love the idea of Wine, and the fact that its working good and rather stable now does mean its gaining popularity and a broader user base, which further IMHO accelerates the wine movement. If wine users were aware of the risks of using wine at present, I believe wine would be used more cautiously.
It should already be used cautiously.
Cant we atleast try implement some protection in wine against these attacks, before something really nasty happens. I do think company policy decissions againt using wine, will do just as much damage to the wine movement as too the free software movement at large.
If you want to implement some of those protections, they should belong at another level, in which case not only Wine would benefit from them.
And don't forget that if you try to build a wall in an open field, there will probably be some gaping holes around, over or under it. Beginning to erect that wall would (IMHO) just entice some people to try to circumvent it.
Use the LSM patches for Linux if you want to monitor certain system calls. Use Wine in UML, chroot, or as a separate user (*not* as SUID) if you want to protect your current $HOME.
I would, despite my current lack of knowledge, gladly offer my help. But I hope someone more experienced would take the lead.
Best Regards,
Peter Andersson
Vincent