I think a "isolate prefix" option in winecfg (or even winetricks) would be very useful. Undoing symlinks and editing the registry to take out the reference to the root is boring (and I'm not sure only doing this is entirely safe) and this kind of option would make it possible to run untrusted software without worrying. I even ran some malwares in isolated wine prefixes and used diff to see what it did. Learned a lot from this. Anyway, a "nice to have" feature.
Best wishes and thanks for this amazing software,
2009/1/14 wine-devel-request@winehq.org
Date: Wed, 14 Jan 2009 15:07:06 -0500 From: Nicholas LaRoche nlaroche@vt.edu Subject: Re: Wine being targeted for adware To: Stefan D?singer stefan@codeweavers.com Cc: wine-devel@winehq.org Message-ID: 496E45EA.9060603@vt.edu Content-Type: text/plain; charset=windows-1252; format=flowed
Stefan D?singer wrote:
As long as the facilities exist for keeping an entire wine bottle isolated from other bottles (and ~/) I don't see this being a major issue.
They don't.
Even if you don't have a drive link pointing out of a bottle, a Windows
app
running in Wine can still call Linux syscalls(int 0x80). This is possible/needed because Windows apps run as a regular Linux process that links in Linux libraries which perform linux syscalls.
So any Windows malware can break out of the Wine "sandbox"(which isn't a sandbox really) by simply using linux syscalls.
On more recent distros (FC9/10) SELinux is enabled by default. Rolling a policy specifically for an untrusted bottle would severely limit the damage it could do. It could restrict all unnecessary read/write/execute access outside of the ~/.wine folder for wineserver and the program.
I see your point though, since none of the aforementioned security precautions are commonplace or specifically targeted to wine.
On Wed, Jan 14, 2009 at 7:23 PM, Eduardo Menezes companheiro.vermelho@gmail.com wrote:
I think a "isolate prefix" option in winecfg (or even winetricks) would be very useful. Undoing symlinks and editing the registry to take out the reference to the root is boring (and I'm not sure only doing this is entirely safe) and this kind of option would make it possible to run untrusted software without worrying. I even ran some malwares in isolated wine prefixes and used diff to see what it did. Learned a lot from this. Anyway, a "nice to have" feature.
Best wishes and thanks for this amazing software,
2009/1/14 wine-devel-request@winehq.org
Date: Wed, 14 Jan 2009 15:07:06 -0500 From: Nicholas LaRoche nlaroche@vt.edu Subject: Re: Wine being targeted for adware To: Stefan D?singer stefan@codeweavers.com Cc: wine-devel@winehq.org Message-ID: 496E45EA.9060603@vt.edu Content-Type: text/plain; charset=windows-1252; format=flowed
Stefan D?singer wrote:
As long as the facilities exist for keeping an entire wine bottle isolated from other bottles (and ~/) I don't see this being a major issue.
They don't.
Even if you don't have a drive link pointing out of a bottle, a Windows app running in Wine can still call Linux syscalls(int 0x80). This is possible/needed because Windows apps run as a regular Linux process that links in Linux libraries which perform linux syscalls.
So any Windows malware can break out of the Wine "sandbox"(which isn't a sandbox really) by simply using linux syscalls.
On more recent distros (FC9/10) SELinux is enabled by default. Rolling a policy specifically for an untrusted bottle would severely limit the damage it could do. It could restrict all unnecessary read/write/execute access outside of the ~/.wine folder for wineserver and the program.
I see your point though, since none of the aforementioned security precautions are commonplace or specifically targeted to wine.
-- Eduardo "Toda Revolução é IMPOSSÍVEL até que se torne INEVITÁVEL!!!" (Leon Trotsky)
Windows doesn't provide this, why would wine?
P.S., please bottom post on wine mailing lists.
Well, Windows doesn't have multiple bottles (prefixes), each one with it's own "windows" directory and registry. This is something "wine specific". Managing prefixes is something "wine specific". Just thought it is a nice feature to protect the rest of the system (your home folder, for example) from some nasty application. I do it by hand on some of my bottles (I separate bottles for each application type and some of then I isolate from some parts of my filesystem). Just to be completely clear, by prefix and bottle I mean the same thing: the ~/.wine for example. Best regards,
2009/1/15 Austin English austinenglish@gmail.com
On Wed, Jan 14, 2009 at 7:23 PM, Eduardo Menezes companheiro.vermelho@gmail.com wrote:
I think a "isolate prefix" option in winecfg (or even winetricks) would
be
very useful. Undoing symlinks and editing the registry to take out the reference to
the
root is boring (and I'm not sure only doing this is entirely safe) and
this
kind of option would make it possible to run untrusted software without worrying. I even ran some malwares in isolated wine prefixes and used diff to see
what
it did. Learned a lot from this. Anyway, a "nice to have" feature.
Best wishes and thanks for this amazing software,
2009/1/14 wine-devel-request@winehq.org
Date: Wed, 14 Jan 2009 15:07:06 -0500 From: Nicholas LaRoche nlaroche@vt.edu Subject: Re: Wine being targeted for adware To: Stefan D?singer stefan@codeweavers.com Cc: wine-devel@winehq.org Message-ID: 496E45EA.9060603@vt.edu Content-Type: text/plain; charset=windows-1252; format=flowed
Stefan D?singer wrote:
As long as the facilities exist for keeping an entire wine bottle isolated from other bottles (and ~/) I don't see this being a major issue.
They don't.
Even if you don't have a drive link pointing out of a bottle, a
Windows
app running in Wine can still call Linux syscalls(int 0x80). This is possible/needed because Windows apps run as a regular Linux process
that
links in Linux libraries which perform linux syscalls.
So any Windows malware can break out of the Wine "sandbox"(which isn't
a
sandbox really) by simply using linux syscalls.
On more recent distros (FC9/10) SELinux is enabled by default. Rolling a policy specifically for an untrusted bottle would severely limit the damage it could do. It could restrict all unnecessary read/write/execute access outside of the ~/.wine folder for wineserver and the program.
I see your point though, since none of the aforementioned security precautions are commonplace or specifically targeted to wine.
-- Eduardo "Toda Revolução é IMPOSSÍVEL até que se torne INEVITÁVEL!!!" (Leon
Trotsky)
Windows doesn't provide this, why would wine?
P.S., please bottom post on wine mailing lists.
-- -Austin
Austin English wrote:
On Wed, Jan 14, 2009 at 7:23 PM, Eduardo Menezes companheiro.vermelho@gmail.com wrote:
I think a "isolate prefix" option in winecfg (or even winetricks) would be very useful. Undoing symlinks and editing the registry to take out the reference to the root is boring (and I'm not sure only doing this is entirely safe) and this kind of option would make it possible to run untrusted software without worrying. I even ran some malwares in isolated wine prefixes and used diff to see what it did. Learned a lot from this. Anyway, a "nice to have" feature.
Best wishes and thanks for this amazing software,
2009/1/14 wine-devel-request@winehq.org
Date: Wed, 14 Jan 2009 15:07:06 -0500 From: Nicholas LaRoche nlaroche@vt.edu Subject: Re: Wine being targeted for adware To: Stefan D?singer stefan@codeweavers.com Cc: wine-devel@winehq.org Message-ID: 496E45EA.9060603@vt.edu Content-Type: text/plain; charset=windows-1252; format=flowed
Stefan D?singer wrote:
As long as the facilities exist for keeping an entire wine bottle isolated from other bottles (and ~/) I don't see this being a major issue.
They don't.
Even if you don't have a drive link pointing out of a bottle, a Windows app running in Wine can still call Linux syscalls(int 0x80). This is possible/needed because Windows apps run as a regular Linux process that links in Linux libraries which perform linux syscalls.
So any Windows malware can break out of the Wine "sandbox"(which isn't a sandbox really) by simply using linux syscalls.
On more recent distros (FC9/10) SELinux is enabled by default. Rolling a policy specifically for an untrusted bottle would severely limit the damage it could do. It could restrict all unnecessary read/write/execute access outside of the ~/.wine folder for wineserver and the program.
I see your point though, since none of the aforementioned security precautions are commonplace or specifically targeted to wine.
-- Eduardo "Toda Revolução é IMPOSSÍVEL até que se torne INEVITÁVEL!!!" (Leon Trotsky)
Windows doesn't provide this, why would wine?
P.S., please bottom post on wine mailing lists.
The vanilla wine distribution probably wouldn't have it due to it being low priority. That doesn't necessarily preclude a patch set from being created that adds that functionality. There are definite advantages to being able to override what an application can access or modify.
Any patches could always be pulled into the official repository if it became a higher priority down the road.
Windows doesn't provide this, why would wine?
See ReactOS for a clone of windows. Wine users should at least have the option of patching in additional security features.
-Nick
On Thu, Jan 15, 2009 at 11:44 AM, Nicholas LaRoche nlaroche@vt.edu wrote:
Austin English wrote:
On Wed, Jan 14, 2009 at 7:23 PM, Eduardo Menezes companheiro.vermelho@gmail.com wrote:
I think a "isolate prefix" option in winecfg (or even winetricks) would be very useful. Undoing symlinks and editing the registry to take out the reference to the root is boring (and I'm not sure only doing this is entirely safe) and this kind of option would make it possible to run untrusted software without worrying. I even ran some malwares in isolated wine prefixes and used diff to see what it did. Learned a lot from this. Anyway, a "nice to have" feature.
Best wishes and thanks for this amazing software,
2009/1/14 wine-devel-request@winehq.org
Date: Wed, 14 Jan 2009 15:07:06 -0500 From: Nicholas LaRoche nlaroche@vt.edu Subject: Re: Wine being targeted for adware To: Stefan D?singer stefan@codeweavers.com Cc: wine-devel@winehq.org Message-ID: 496E45EA.9060603@vt.edu Content-Type: text/plain; charset=windows-1252; format=flowed
Stefan D?singer wrote:
As long as the facilities exist for keeping an entire wine bottle isolated from other bottles (and ~/) I don't see this being a major issue.
They don't.
Even if you don't have a drive link pointing out of a bottle, a Windows app running in Wine can still call Linux syscalls(int 0x80). This is possible/needed because Windows apps run as a regular Linux process that links in Linux libraries which perform linux syscalls.
So any Windows malware can break out of the Wine "sandbox"(which isn't a sandbox really) by simply using linux syscalls.
On more recent distros (FC9/10) SELinux is enabled by default. Rolling a policy specifically for an untrusted bottle would severely limit the damage it could do. It could restrict all unnecessary read/write/execute access outside of the ~/.wine folder for wineserver and the program.
I see your point though, since none of the aforementioned security precautions are commonplace or specifically targeted to wine.
-- Eduardo "Toda Revolução é IMPOSSÍVEL até que se torne INEVITÁVEL!!!" (Leon Trotsky)
Windows doesn't provide this, why would wine?
P.S., please bottom post on wine mailing lists.
The vanilla wine distribution probably wouldn't have it due to it being low priority. That doesn't necessarily preclude a patch set from being created that adds that functionality. There are definite advantages to being able to override what an application can access or modify.
Any patches could always be pulled into the official repository if it became a higher priority down the road.
Of course, Wine is open source, so if someone wants to edit it for that purpose, by all means, do so. I'm not sure that Wine _should_ do so though, at least, not now. Networking on a per app basis I can see an argument for, since Windows Firewall is now included and provides such a feature.
Windows doesn't provide this, why would wine?
See ReactOS for a clone of windows. Wine users should at least have the option of patching in additional security features.
Again, they can do as they wish, but that doesn't mean it needs to be in vanilla wine.
On Thu, Jan 15, 2009 at 7:50 PM, Austin English austinenglish@gmail.com wrote:
Of course, Wine is open source, so if someone wants to edit it for that purpose, by all means, do so. I'm not sure that Wine _should_ do so though, at least, not now. Networking on a per app basis I can see an argument for, since Windows Firewall is now included and provides such a feature.
Can't SELinux or something similar disable network access per-application?
I would think that this kind of functionality should be provided by the OS, not by Wine. (Having control over what can / can't get to the network can be real handy for purposes such as server-hardening.) (Solaris Trusted Extensions seem to provide this kind of functionality...)
Wine should probably at least provide APIs that can be used by anti-malware applications... (I'm not sure about recent applications, but, IIRC, older ones under Windows 9x used to use drivers for on-access scanning which is not currently supported in Wine)
Gert
Gert van den Berg wrote:
On Thu, Jan 15, 2009 at 7:50 PM, Austin English austinenglish@gmail.com wrote:
Of course, Wine is open source, so if someone wants to edit it for that purpose, by all means, do so. I'm not sure that Wine _should_ do so though, at least, not now. Networking on a per app basis I can see an argument for, since Windows Firewall is now included and provides such a feature.
Can't SELinux or something similar disable network access per-application?
I would think that this kind of functionality should be provided by the OS, not by Wine. (Having control over what can / can't get to the network can be real handy for purposes such as server-hardening.) (Solaris Trusted Extensions seem to provide this kind of functionality...)
Wine should probably at least provide APIs that can be used by anti-malware applications... (I'm not sure about recent applications, but, IIRC, older ones under Windows 9x used to use drivers for on-access scanning which is not currently supported in Wine)
Gert
It probably does disable network access, but you would have to play around with policies on the fly to accomplish this. If a patch were made to disable it within wine then you could turn it on and off with a command line switch. One takes more time than the other, but both should be valid.
-Nick
-
Austin English -
Eduardo Menezes -
Gert van den Berg -
Nicholas LaRoche