Wine securityflaw.

[Greg Turner]

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.

-- 
gmt

"The purpose of government is to rein in the rights of the people"
 --President Bill Clinton, MTV interview, 1993