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 up "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 quickly.
Cheers, Geoff