Another virus-in-wine story

[Nicholas LaRoche]

Scott Ritchie wrote:
> 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
> 

 From a usability standpoint, adding switches to wine for sandboxing is 
a good thing. But it seems to only cover the APIs exported by wine. A 
specially crafted win32 wine-aware malware app could leverage 
sys_open(1) and sys_write(4) via int 80h to bypass this isolation and 
install itself anywhere in the users home directory.

e.g. this malware could open ~/.bashrc and install linux specific 
malware that executes the next time you open a shell.

Perhaps the app-specific package that you mentioned can be shipped with 
an AppArmor/SELinux profile that prohibits syscalls from originating 
anywhere in user code. (Assuming that the other sandboxing changes are 
made to wine).

Should it be up to the distro maintainers to add these profiles?

-Nick