Another virus-in-wine story

[Damjan Jovanovic]

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
>> 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