Another virus-in-wine story
damjan.jov at gmail.com
Mon Oct 26 02:20:07 CDT 2009
On Mon, Oct 26, 2009 at 4:22 AM, Nicholas LaRoche <nlaroche at 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
>> 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.
static inline int epoll_create( int size )
__asm__( "pushl %%ebx; movl %2,%%ebx; int $0x80; popl %%ebx"
: "=a" (ret) : "0" (254 /*NR_epoll_create*/), "r" (size) );
So yes we do syscalls straight from wine.
More information about the wine-devel