This is about the fifth article of this sort, so it's not really news anymore, but it's still fun to read about. TFA is clueless about how to clean up a wine installation (he thought uninstalling wine would do it), buts lots of readers supply the missing clue. http://linux.slashdot.org/story/09/10/24/1759213/Now-Linux-Can-Get-Viruses-V...
Dan Kegel wrote:
This is about the fifth article of this sort, so it's not really news anymore, but it's still fun to read about.
TFA is clueless about how to clean up a wine installation (he thought uninstalling wine would do it), buts lots of readers supply the missing clue.
http://linux.slashdot.org/story/09/10/24/1759213/Now-Linux-Can-Get-Viruses-V...
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. -Nick
On Sat, Oct 24, 2009 at 10:47 PM, Nicholas LaRoche <nlaroche(a)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
Dan Kegel wrote:
On Sat, Oct 24, 2009 at 10:47 PM, Nicholas LaRoche <nlaroche(a)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
On Sun, Oct 25, 2009 at 10:57 AM, Scott Ritchie <scott(a)open-vote.org> wrote:
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.
http://sandboxing.org/ was just formed to discuss such a thing... - Dan
Am 25.10.2009 um 10:57 schrieb Scott Ritchie:
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. The usual reply to this is that Windows apps in Wine can just issue Linux system calls, so any Wine-based sandboxing is security by obscurity. You need something at the syscall layer.
Stefan Dösinger wrote:
Am 25.10.2009 um 10:57 schrieb Scott Ritchie:
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. The usual reply to this is that Windows apps in Wine can just issue Linux system calls, so any Wine-based sandboxing is security by obscurity. You need something at the syscall layer.
Could Wine ship two binaries, one with an AppArmor profile blocking syscalls and one without? Then a simple switch could tell Wine which one to use and that functionality wouldn't need to be duplicated elsewhere. Thanks, Scott Ritchie
Scott Ritchie wrote:
Stefan Dösinger wrote:
Am 25.10.2009 um 10:57 schrieb Scott Ritchie:
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. The usual reply to this is that Windows apps in Wine can just issue Linux system calls, so any Wine-based sandboxing is security by obscurity. You need something at the syscall layer.
Could Wine ship two binaries, one with an AppArmor profile blocking syscalls and one without? Then a simple switch could tell Wine which one to use and that functionality wouldn't need to be duplicated elsewhere.
Thanks, Scott Ritchie
Is there any valid use for syscalls in wine? Most of the functionality that might be gained by using a syscall directly probably already exists in libc or some other library. These libraries can have granular security policies applied to them as opposed to granting full access to the core wine binary. -Nick
On Mon, Oct 26, 2009 at 4:22 AM, Nicholas LaRoche <nlaroche(a)vt.edu> wrote:
Scott Ritchie wrote:
Stefan Dösinger wrote:
Am 25.10.2009 um 10:57 schrieb Scott Ritchie:
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.
The usual reply to this is that Windows apps in Wine can just issue Linux system calls, so any Wine-based sandboxing is security by obscurity. You need something at the syscall layer.
Could Wine ship two binaries, one with an AppArmor profile blocking syscalls and one without? Then a simple switch could tell Wine which one to use and that functionality wouldn't need to be duplicated elsewhere.
Thanks, Scott Ritchie
Is there any valid use for syscalls in wine?
Most of the functionality that might be gained by using a syscall directly probably already exists in libc or some other library. These libraries can have granular security policies applied to them as opposed to granting full access to the core wine binary.
-Nick
server/fd.c: static inline int epoll_create( int size ) { int ret; __asm__( "pushl %%ebx; movl %2,%%ebx; int $0x80; popl %%ebx" : "=a" (ret) : "0" (254 /*NR_epoll_create*/), "r" (size) ); SYSCALL_RET(ret); } So yes we do syscalls straight from wine. Damjan
On Sun, Oct 25, 2009 at 06:14:34PM -0700, Scott Ritchie wrote:
Stefan Dösinger wrote:
Am 25.10.2009 um 10:57 schrieb Scott Ritchie:
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. The usual reply to this is that Windows apps in Wine can just issue Linux system calls, so any Wine-based sandboxing is security by obscurity. You need something at the syscall layer.
Could Wine ship two binaries, one with an AppArmor profile blocking syscalls and one without? Then a simple switch could tell Wine which one to use and that functionality wouldn't need to be duplicated elsewhere.
AppArmor does not do system call level blocking. You could use AA to confine an app to write just in $HOME/.wine/ itself. Ciao, Marcus
Scott Ritchie wrote: > Dan Kegel wrote: >> On Sat, Oct 24, 2009 at 10:47 PM, Nicholas LaRoche <nlaroche(a)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
2009/10/25 Nicholas LaRoche <nlaroche(a)vt.edu>:
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.
Yes. It would be exceedingly foolish to claim to offer security that cannot be delivered. (I'd sugest big warnings. "WARNING: any Windows app can do anything on your system that the user it is running as can do. If you want to study malware, use WineZero or similar.")
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).
This would need some really serious testing before making such a promise, of course. i.e., will Wine itself still work? - d.
On Sun, Oct 25, 2009 at 2:18 PM, Nicholas LaRoche <nlaroche(a)vt.edu> wrote:
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.
Yes. That's why I don't think win32-only sandboxing is sufficient. A native sandbox is needed to provide any real security. sandboxing.org talks about various implementations of native sandboxes for linux. Chrome's, for example, are described here: http://sandboxing.org/?page_id=13 Many of them are based on chroot, but there are also ones based on seccomp and selinux. It would be interesting to, for instance, offer a truly secure sandboxed wine to run ie7 in... - Dan
On Sa, 2009-10-24 at 22:07 -0700, Dan Kegel wrote:
This is about the fifth article of this sort, so it's not really news anymore, but it's still fun to read about. http://linux.slashdot.org/story/09/10/24/1759213/Now-Linux-Can-Get-Viruses-V...
The blogger mention the bad website, but the malware file change to often. Yesterday, you will get a fake "Adobe Flash Player.exe" (crash early in Wine) after redirection to a different Website (looks like facebook.com): http://www.virustotal.com/analisis/a7c8ccfd07652f8622edb3f7ea2bbb975ddb3a74d... Today, you will receive "surprise.exe" (crash early in Wine) from the Website: http://www.virustotal.com/analisis/8f753cbb1ddc3edda4a0b4ec0ce14475c2ed5e589... -- By by ... Detlef
participants (8)
-
Damjan Jovanovic -
Dan Kegel -
David Gerard -
Detlef Riekenberg -
Marcus Meissner -
Nicholas LaRoche -
Scott Ritchie -
Stefan Dösinger