chaos at swi.com.br
Thu Oct 31 08:10:33 CST 2002
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
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)
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.
Alexandre Julliard <julliard at winehq.com> wrote:
>Peter Andersson <kanelballe at 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.
>julliard at winehq.com
More information about the wine-devel