My $0.02,
I always though of a wine as way to run windows apps better than windows.
Better also means "more secure" for me.
A way to make it more secure is to catch key API calls and decide if the application is allowed to run it or not.
This would be easy to detect if an application is trying to delete a file, to open a network connection, or anything that could be possible unsafe if not used correct.
As this would be implemented in wine (as opposed in the host OS, e.g. the Linux kernel) a Dialog could pop up telling the user what the app is trying to do and how the user would like to proceed, like: <allow this time>, <allow this session>, <always allow>, <deny this time>, ... and so on.
This could be configured in the config as the dll loading is done now in a per app way or generic (all apps) way.
Of course, this being implemented in wine as a wrapper to such API calls would slow the performance a little, so wine could be compiled with '--disable-runtime-security' is configure or something like that. This way wine could be compiled just as if this feature did not existed (as it is now).
I know this is not a priority to wine project right nowand there is a lot of things to be done to get to wine 0.9 and 1.0.
However, I do think that just setting this to a OS problem and that wine should not care about this is wrong. Maybe this is just not the right time to implement this, but this shouldn't be banned.
I agree that you shouldn't run any untrusted code as people would not do with Linux/Bsd/..., however there is a strong point here.
99.9999% of win32 applications is closed source. There is no way to trust them.
Even common ones like MS Office can be exploited and used to run mallicious code. Codeweavers would need to handle this later on.
Internet Explorer can run potencially untrusted/dangerous code with ActiveX from webpages. And its use is already advertised with Codeweavers Xover Office (not supported though).
Many programs already install some kind of spyware nowadays, like any p2p as Kazaa, morpheus, edonkey2000, ...
Even RealPlay used to send private information thru the net.
As Wine gets more and more reliable to run win32 applications and Microsoft change its EULA to not run applciations like Media Player in other OSes that Windows. And this discussion of syscalls that only wine as a linux application could do, could make future versions of MS apps use this to exploit limitations as the wine drivers and wipe everything it has permissions to. And this would be leagal as no one really reads the EULA.
Note that I did not get to the merity of Virus that nowadays are the number one reason people are moving to (or willing to) Linux.
Wine could implement a clean Security Layer: YES
Is this a priority for Wine Project: NO (not yet at least)
This kind of stuff is what would make Wine a possibility run run Windows Apps better than Windows.
Because of this points, I would like to ask Alexandre to not deny the possibility to a developer to try to implement this kind of layer of security.
I agree that this needs to be deeply discussed on how it should be implemented and that after some start to implement this, this could take a long time before being merged in the main tree.
However, this is not just a OS problem IMO.
Regards,
Raul Dias
Alexandre Julliard julliard@winehq.com wrote:
Peter Andersson kanelballe@softhome.net writes:
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.
You should. If you run untrusted code under your account it can do anything that you are allowed to. This is exactly equivalent to running an untrusted Linux app. From a security standpoint there is absolutely no difference between a Windows binary running under Wine and a Linux binary running natively.
You can use the DOS drive configuration to limit the potential problems a bug in a Windows app can cause; but it is impossible to protect against malicious code except by not running it. Wine is not, and cannot be, a sandbox for running untrusted code.
Cant we atleast try implement some protection in wine against these attacks, before something really nasty happens.
No, we can't.
-- Alexandre Julliard julliard@winehq.com