I think a "isolate prefix" option in winecfg (or even winetricks) would be very useful.<br>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.<br>
I even ran some malwares in isolated wine prefixes and used diff to see what it did. Learned a lot from this.<br>Anyway, a "nice to have" feature.<br><br>Best wishes and thanks for this amazing software,<br><br>
<div class="gmail_quote">2009/1/14 <span dir="ltr"><<a href="mailto:wine-devel-request@winehq.org">wine-devel-request@winehq.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Date: Wed, 14 Jan 2009 15:07:06 -0500<br>
From: Nicholas LaRoche <<a href="mailto:nlaroche@vt.edu">nlaroche@vt.edu</a>><br>
Subject: Re: Wine being targeted for adware<br>
To: Stefan D?singer <<a href="mailto:stefan@codeweavers.com">stefan@codeweavers.com</a>><br>
Cc: <a href="mailto:wine-devel@winehq.org">wine-devel@winehq.org</a><br>
Message-ID: <<a href="mailto:496E45EA.9060603@vt.edu">496E45EA.9060603@vt.edu</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
Stefan D?singer wrote:<br>
>> As long as the facilities exist for keeping an entire wine bottle<br>
>> isolated from other bottles (and ~/) I don't see this being a major<br>
>> issue.<br>
> They don't.<br>
><br>
> Even if you don't have a drive link pointing out of a bottle, a Windows app<br>
> running in Wine can still call Linux syscalls(int 0x80). This is<br>
> possible/needed because Windows apps run as a regular Linux process that<br>
> links in Linux libraries which perform linux syscalls.<br>
><br>
> So any Windows malware can break out of the Wine "sandbox"(which isn't a<br>
> sandbox really) by simply using linux syscalls.<br>
><br>
><br>
><br>
<br>
On more recent distros (FC9/10) SELinux is enabled by default. Rolling a<br>
policy specifically for an untrusted bottle would severely limit the<br>
damage it could do. It could restrict all unnecessary read/write/execute<br>
access outside of the ~/.wine folder for wineserver and the program.<br>
<br>
I see your point though, since none of the aforementioned security<br>
precautions are commonplace or specifically targeted to wine.<br>
<br>
</blockquote></div><br>-- <br>Eduardo<br>"Toda Revolução é IMPOSSÍVEL até que se torne INEVITÁVEL!!!" (Leon Trotsky)<br>