SecuringWine - The Official Wine Wiki

Securing Wine

Wine doesn't support most Windows security constructs, and instead relies on the underlying operating system for security. Unless you run Wine as root, for instance, it's hard for malicious software in Wine to modify files belonging to other users. But Wine doesn't protect you against malware you run yourself.

End of story.

Except... there are a few weak things you can do to slightly protect yourself.

Easy measures

One can run each window app in its own bottle, and remove and disable executables that its app doesn't need (e.g. once you've set up a bottle, it probably doesn't need winecfg anymore).

"winetricks sandbox" removes the Z:\ mapping and the symlinks to $HOME... at least until you install ie6 or something that triggers a simulated windows reboot.

One can run clamscan or another antivirus package on Windows binaries manually before running them in Wine.

One can use AppArmor to create a profile for an individual windows app (see e.g. http://ubuntuforums.org/showthread.php?t=918510 ). (Updated recipe, anyone?)

One can disable the workaround for the PreloaderPageZeroProblem, as long as you don't need to run DOS apps.

Distributions can also prevent the unintentional running of applications by requiring the user to explicitly say they want to open something with Wine (and not have it be the default action on, say, download via Firefox or Evolution)

Moderate measures

Maybe SELinux could help. (See also http://danwalsh.livejournal.com/37067.html, http://lwn.net/Articles/342573 )

One can run wine apps as a separate user. (Recipe, anyone?)

One can run wine inside a chroot jail. (Recipe, anyone?)

Harder, attractive, yet futile measures

It's probably possible to modify wineserver to disallow windows apps from doing any networking (unless they use linux system calls directly).

It's probably possible to modify kernel32 to disable executing linux apps from inside windows apps (unless they use linux system calls directly).

Remaining holes

How can we prevent the c:/user/foo symlinks from being recreated on a simulated reboot?

I know of no way to prevent win32 malware from issuing linux system calls directly.

One could potentially scan PE modules when loading them to detect and disallow system calls, but it might be hard to enumerate all the ways to call system calls (int 80, sysenter, call ffffef00, call *%gs:0x10, etc.), and there might be lots of false positives. However, dynamic code generation or code packing methods easily defeat this.

One could ask the kernel guys to add a "no syscalls from this VMA" option to mprotect, but that's not likely to go over too well.