Another virus-in-wine story

[Scott Ritchie]

Dan Kegel wrote:
> On Sat, Oct 24, 2009 at 10:47 PM, Nicholas LaRoche <nlaroche at vt.edu> wrote:
>> A few months ago there was a topic in wine-devel on the same subject. A
>> toggle switch for portions of the wine API (i.e. networking), WINEPREFIX,
>> and SELinux seems to make this a non-issue.
>>
>> The default wine SELinux configuration for Fedora 11 denies quite a bit of
>> behavior. (Try compiling and using HEAD without setting the security context
>> or entering permissive mode and you'll see what I mean).
>>
>> Does this even need to be handled at the wine level to prevent system-wide
>> corruption? It seems like other security technologies already provide this
>> protection.
> 
> We may want to lend a hand.  For instance, I could imagine
> the system needing some help to figure out how to allow
> certain windows apps access to the network, and deny it
> to others.  And I think sandboxing a la chromium might end
> up being a useful technique that would require some work on
> wine's part to work well.
> - Dan
> 

Sandboxing is certainly an interesting idea if we want to expand the
role of Wine-specific packages (a la Picassa).  I've been experimenting
with shipping a Windows (or winelib) app via a distro package configured
to run in its own prefix.  This in particular could benefit from
sandboxing, as then security holes in that application wouldn't take
down the rest of the user folder.

Many apps don't need to view the user folder for documents but also
employ programmable scripting engines - a good example are games.  It
would be much more convenient to pass some sort of "sandbox me, allow
network, deny home folder access" switch to Wine than to muck about with
stuff like AppArmor profiles.

Thanks,
Scott Ritchie