On Mon, Oct 26, 2009 at 4:22 AM, Nicholas LaRoche nlaroche@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