Slashdot Mirror
Can WINE Compromise Unix?
gbulmash asks: "As API's like WINE and Crossover Office gradually make it easier to run Windows binaries on Unix, will the system inherit some of Windows' vulnerabilities? For example, has anyone tried to get Outlook up and running under Wine, then deliberately tried to infect themselves with a Windows virus to see if it could raid the Outlook address book and start mailing itself out? It just seems to stand to reason that the better these systems get at running Windows binaries, the easier it will become to infect them with Windows viruses. Or am I just totally off base here?"
You'd be surprised. At work, we are on an Exchange mail/scheduling backend, and since I don't have Windows, I run Outlook under Wine - some of the time. Most of the time, I just use Outlook Web Access in my browser.
I think the greater risk involved in widespread availability of WINE is the possibility that developers will feel even less need to code natively for linux - a necessary evil, I suppose. Also, wine doesn't require you to run as root (IIRC). Of course, non-privilege elevation exploits like outlook virus email spam will be possibilities - why do you even have cause to think differently? You can use mozilla instead of outlook, or implement filtering at your mail server. Just don't execute attachments, apply the MS patches and so on.
"The slave who knows his master's will and does not get ready...will be be beaten with many blows."Luke 12:47-48
The big advantage to something like wine (or to a lesser extent, dosemu, mars, etc.) is that you can insert shims at pretty much any level to catch / filter / stop / watch this sort of thing. I find it amazingly useful to be able to instrument & monitor pretty much any level I want (with the usual cavets about making sure you don't break things by inapropriate logging, etc.). It shouldn't be too hard to put a rubber-room/internal firewall around whatever infection prone software you felt like running, and stopping these things dead in their tracks. (e.g., by default, cap the rate at which network trafic can flow out of applications running under wine, lower the boom if they try to send out too much e-mail too quickly, etc).
-- MarkusQ
Remember just like networking software has levels also. In the case of windows and viruses It would seem that there are 4 levels you need worry about. The bottom most lasyer is of course the core of the OS the kernel, layer 1 would be the OS interoperability layer, layer 2 the api and layer 3 the application itself. ( yes you could break them down into finer layers but for this argument 4 is fine.) Running wine layers 0 and 1 are replaced completely. Layer 2 is a functional and structural equivalent. Any virus based on its concepts should in effect still work, however most at that level are specific code exploits. Most importantly you have the application layer (3) since this code is teh same any virus designed to run exclusively in this layer should by all means be fully functional. Fortunately this is going to be in user space and should not affect he rest of teh system outside of the specific application.
Bad Panda! No Bamboo for you! In matters of importance ACs will not be responded to. Want to say something critical,OK
> That's why I don't run WINE and have absolutely no appreciation
> for the WINE project.
Too narrowminded. There are a lot of legacy win32 apps in regular use out there that won't get ported. Many times it is impossible to even locate the source or any design docs. It only takes ONE to keep a machine chained to Windows. If it takes wine to get that desktop converted it is still a win. Because once the conversion has taken place that shop probably won't invest in MORE win32 software and eventually those stragglers will get discarded as the relentless march of time obsoletes dead end programs that aren't being well maintained and probably never worked flawlessly in the first place.
Democrat delenda est
Generally, I try to set things up so the Windows instance doesn't have any ports open to the world, and if at all possible, its "filesystem" is within a file in the real filesystem, so it can't trash anything but itself. :)
You miss the key aspect of the point that was being made. People are switching to Linux because it reduces the cost of support as well as the cost of implementation. However, the point was that there are still a lot of apps that run on Windows platforms for which there are no alternatives in the Linux world. Why give up all the extra benefits of Linux for just one or two applications for which no alternative exists?
;-)
The point of the WINE project is to provide that bridge. Get all the benefits of using something like Linux or BSD, get all the alternatives available to you (freely or otherwise) and if there are a few you need Windows for, use WINE to run them under Linux. Someone running Outlook under Linux would be a lot better off running Evolution and paying for the Connector license (cheaper licensing and native). However, someone running a core accounting app for which no Linux alternative exists is going to want to use WINE so they can still use that application AND get the benefits of the Linux alternatives for everything else.
WINE is a bridging tool for those migrating from Windows to Linux/Unix but who have applications for which no feasible Linux/Unix alternatives exist.
I would much prefer to save the costs involved in getting a Linux box up and running with WINE that spend the several hundred in licensing just for a few applications.
Hmmm...
($time to get up and running) vs ($time + $licensing costs for Windows)
Which is really the cheaper in the end? Support? Bah, its remote. Like you say, there is VNC if it comes down to it (bad solution really) but X across an SSH session is a lot better (regardless of how badly people think of the X protocol, it does its intended job very well still)
Just my $0.02. We differ in our opinions, but thats the beauty of diversity in life