Wine securityflaw.

[Francois Gouget]

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.


-- 
Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
     The software said it requires Win95 or better, so I installed Linux.