Peter Andersson a écrit:
Hello again,"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.
(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.
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 checkingIt 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?
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.
How do you know it _is_ safe to run in Windows? Because you never had a problem running it? Hardly a proof, no?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?
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.
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.
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.
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
