On Saturday 26 October 2002 08:32 pm, Vincent Béron wrote:
Peter Andersson a écrit:
Malicious Linux/Unix syscalls could be embedded in windows apps and if executed do a great deal of damage.
And don't forget that if you try to build a wall in an open field, there will probably be some gaping holes around, over or under it. Beginning to erect that wall would (IMHO) just entice some people to try to circumvent it.
Use the LSM patches for Linux if you want to monitor certain system calls. Use Wine in UML, chroot, or as a separate user (*not* as SUID) if you want to protect your current $HOME.
Vincent
I concur with Vincent, here. As wine exists here and now, we are basically implementing the level of "security" provided by Windows 9x. That is, wine "emulates" an OS with no security measures at the filesystem level, no security policy regarding what API's can be called (except as provided by the CPU itself), and so on.
Luckily, the native operating systems that host wine tend to be rich with security features, and those can be used to sandbox wine until some more sophisticated application-level security measures exist.
We've recently talked about some ways to move forward towards implementing the NT-style security model in wine. When those plans move forward, one of the issues to consider is the tendency of windows to propogate virii, and the possible need to selectively prohibit wine from accessing resources that the user invoking wine might have full control of.
Unless wine is going to be a true emulator (instead of an engine for executing windows apps natively under the security context of the invoking user), we simply cannot solve this "problem," by definition.
The closest thing to a solution involves a massive reconceptualization of how wine works (for example, the invoking user runs userwine, which uses some kind of IPC to talk to sandbox-wine, which does all the actual executing of windows code or, alternatively, wine works like a just-in-time compiler, verifying code is safe before it's loaded into memory (terrible idea IMHO)). Since "emulating" the NT security model for wine is a similarly major undertaking, and provides most of the same benefits as Peter would have, I think this is how we should solve this "problem".
Food for thought: by Peter's definition, neither Windows, nor most Unix operating systems, provide an acceptable level of security. Wine is no better, but also no worse, than any other powerful application, such as GNU make, bash, or the Konqueror file browser, from a security perspective. All of these can be used to destroy your $HOME directory and any other file you can delete.
I think the problem is one of wine being closely associated with Windows, and windows having a reputation of being insecure; in other words, it's a problem of perception, not of technical merit. Nothing wrong with that -- problems of perception can kill a project -- but bear in mind that, if wine, even as it exists today, is run in a carefully administered manner on a good secure OS, it ought to be safer than native Windows to run, if you accept the assumption that UNIX-like OS's are more secure than Windows ones. If you really don't trust windows, you could argue that running under wine in a sandbox is the /only/ safe way to run windows programs outside of an emulator.
Just my opinion, probably worth about what you paid for it, but there you go.