On Fri, Jun 5, 2009 at 10:33 PM, oiaohm<wineforum-user@xxxxxxxxxx> wrote: >> If Wine is running on Linux, it can always be detected by making Linux syscalls. Wine cannot fix this. > > Other than the fact the secuirty systems of Linux can watch syscalls. So calling 1 that wine don't use equal dead application. Yes it is even possible to block sys-calls from inside wine loaded exe's from the Linux system itself while allowing the dll.so files of wine perform syscalls. I do keep my eyes on what prototype secuirty systems exist. It's certainly possible for a kernel to do such things, but it's misguided. The ability to use syscalls directly isn't the problem. It's just an example. I'll try to explain better. Wine must interface directly with the host OS. It might be running in a virtual machine or unprivileged user or chroot jail, but the fact is there is a Unix-like system that Wine interacts with. Wine and the application share a process. There is no security layer between them. The application can branch directly to anywhere in Wine code, whether or not it was meant to be at an entry point or even the address of an instruction. It can mess with internal Wine data structures with impunity. The fact is, from a security standpoint, Wine and the software it runs are the same. If the software cannot be trusted, the Wine libraries cannot be trusted either. That is what I mean by saying Wine cannot provide any security. OK, great, you can reject syscalls that don't come from the .dll.so. Maybe now I'll just branch directly to an interrupt instruction in a .dll.so that makes the syscall. Or maybe I'll find the file API's in the C library. Heck, I bet if I branched to the right point in NtOpenFile, I could fool it into accepting a Unix path. Who knows? What you're talking about is creating a minefield. If I'm just trying to do generic evil Unix-specific things, there's a fairly good chance I'll run into a mine. But if I know how your specific system works and make a directed attack against it, I can get through the minefield and get to whatever it is Wine sees. It's possible (even likely, given the hooking and other crazy stuff they often do) that a real application that someone wants to run trips one of these mines, and if that happens the user loses. Assuming that you do not trust my program, "whatever it is Wine sees" should be not particularly useful. If that doesn't break your security, why bother setting up the crazy minefield that probably only causes headaches for users? If it does break your security, well, then it's already broken. > Wine could make it simpler by the way. Method is what LUK has been doing. Add a set of syscalls to the OS kernel itself for wine. Using anything else could be disregard. Since the syscalls would be emulations of windows it would effectively render you blind. It is foolish to claim something cannot be fixed in software. Software everything basically can be fixed its a pure question of time and resources. I don't claim it cannot be fixed in software. I do claim it cannot be fixed by a userspace library that shares a process with untrusted code. > Wine does not need to fix this at this stage due to OS secuirty. I was not claiming wine contained a sandbox. Wine can be sandbox by the secuirty system in Linux. So leading to problems. Its so simple to think just because you detect wine that you can now do whatever you like. This is not windows. Doing whatever you like equals dead applications. > > Problem with detecting wine without asking is if wine is sandboxed you end up doing things that get programs terminated. Most people planing work around most likely are planing to reach out to native code that can major upset the secuirty system of Linux. When I say that Wine cannot provide security, I don't mean that running a program in Wine is automatically at least as insecure as running it on Windows. Unix systems can provide great security, and Wine can run Windows programs in those systems. Wine automatically benefits from any security provided by the host system. It can be sandboxed by the OS, just like any other program. However, you are talking about a sandbox surrounded by mines instead of nice padded walls. That's a new concept to me. It seems very silly and likely to cause more problems than it solves. If a distro does this, we'll have to explain to some users that Wine is broken on that distro because the security guys are nuts. If someone sets this up on his own machines, we may have to explain to him that Wine is broken on his machines because he is nuts. I'd worry that I may one day have to explain to you that Wine hates you because you are nuts, but it sounds like you'd just blame the application developer instead of asking me. Vincent Povirk
