On Sat, 26 Oct 2002, Greg Turner wrote: [...warning: slight reordering...]
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
[...]
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.
I agree that there is a problem of perception so I will quickly clarify the above sentence, lest it be mis-interpreted and contribute to that perception problem.
When reading 'wine "emulates" an OS with no security measures at the filesystem level' I think most people will think that Windows applications running under Wine can read and modify any file on the Unix system, including system files and files not belonging to the user running the application. This is of course not the case!
What Vincent says is that Wine does not implement the Windows APIs that let a process query or specify ACLs on files or kernel objects, and query or switch user or group ids. In this respect, it is closer to Windows 9x than Windows NT.
However while on Windows 9x this means a process can modify any file on the system (i.e. no security at all), in Wine this just means that Windows applications run under the Unix security model, but have no way to even tinker with it using their usual (Win32) API.
So to sum up: * Win9x No security * Wine Unix security model. * Windows NT/2000/XP NT security model, i.e. an ACL-based one. (only if using an NTFS filesystem)
(however I will quickly point out that the NT security model suffers from a serious design flaw which lets processes escalate privileges in a way which is currently simply impossible in Wine, for more details see http://security.tombom.co.uk/shatter.html)
[...]
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".
AFAIK the Win32 API (unlike the Unix API, see chroot) does not make it possible to prevent a process from accessing or modifying files belonging to the current user.