Wine securityflaw.

Geoff Thorpe geoff at
Thu Oct 31 21:55:33 CST 2002

Hi there,

On Thursday 31 Oct 2002 2:21 pm, David Fraser wrote:
> I think this is missing the point.

No, I think you're stuck on a point that wine is simply destined (ie. as
in "fate") to miss on both our behalves. I'm talking about a different
point where some useful headway could be made.

> The way to make something secure isn't to make big software companies
> worry about
> anti-trust, or virus writers worry they might get sued for writing a
> virus. Big companies
> aren't likely to write wine-specific special workarounds that do nasty
> things, and virus
> writers couldn't care less.

This is an opinion stated as fact, and I don't understand how this is
relevant to the points I made.

> Any security improvements should be normal UNIX ideas like letting a
> wineserver
> do certain priviledged tasks running as a special user, while standard
> wine programs
> run as a different, non-priviledged user. In other words, the kernel
> layer in Windows
> should have higher priveledges than standard user processes, but not
> run as root.

I don't know exactly how the roles are divided up in the wineserver
protocol, but for your suggestion to actually work naturally using
"normal UNIX ideas", you would need to inverse the sense of the
privilege separation. Ie. wine programs (and loaders, etc) would have to
run as a special user ("nobody" perhaps) and to have the wineserver run
as the "normal user". Otherwise, how else will you have win32
application behaviour integrate sanely with the native UNIX permissions?

However, that still *requires* that the wineserver is actually doing all
the work and the wine processes that load and link PE images are doing
very little except marshalling the win32 API back and forth to the
wineserver. I'm not convinced that's the case but would be thrilled to
find out if it was. Ie. does wineserver handle all translation from
win32 to native? GUI? network? file-system? Or does some
"permission-sensitive" functionality translation happen directly from
the PE-loaded processes by way of some linking-in of Wine's win32
implementation? I fear the latter, if for no other reason that the
performance would probably suck if *everything* was marshalling back and
forth to wineserver. If so, this makes privilege separation no more
secure than what I suggested but a lot more hassle.

So if the PE-loaded executables need to run as your "normal" user to
have any meaningful/useful functionality, then you're stuck back with
the comments I made in my previous post. Admittedly they don't construct
a (impenetrable except through wine bugs) "secure" wall against any
PE-payloaded anti-wine virus, but (a) this does prevent "regular"
(non-trojan) PE images from misbehaving on wine in ways they wouldn't
misbehave on MS-windows, and (b) it lets wine exercise a far more
flexible, fine-grained, and extensible configuration over how
win32-based applications behave - better than you can get in any MS
version of windows, and in fact better in many ways that you can get
with native applications on Linux/****BSD/etc ;-)

Eg. imagine if I could specify a flag when executing wine that would
"stick" a label to all subsequent wine processes - eg. if I run;

   $ wine --sticky=WEB "C:\\...\\iexplore.exe"

then my wine configuration could specify extra restrictions for the
"WEB" label (only allow network access on TCP/IP to address
'squid.localnet', only allow write access to certain fixed directories,
prompt the user if it tries to open new windows, etc). This is the sort
of thing I mean - you can't even do it in MS windows. You could also set 
"special" root-like behaviours - eg. if you want to run IIS to listen
on port 80 and 443 (something only root can do in *nix), you could set
up a wine configuration such that it would (a) report an error unless
you start it as root, (b) create sockets bound to ports 80 and 443, (c)
change back to the "normal" user, (d) intercept any future win32 calls
that try to create listening sockets on 80 and 443 and let them use the
ones it already created. The possibilities are obviously wide-open and
I'm not necessarily suggesting any of the above should be implemented in
that form - but I certainly think having Wine's PE-loader let win32
applications bind directly to native libraries (glibc for example) make
the security and flexibility elements of all this disappear quite


Geoff Thorpe
geoff at

More information about the wine-devel mailing list