Hi there,
On Friday 01 Nov 2002 8:23 am, Ove Kaaven wrote:
On Thu, 31 Oct 2002, Geoff Thorpe wrote:
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?
The wineserver doesn't do any GUI as such, but it does handle message queues. It's also responsible for handling win32 requests for opening files and creating network sockets. Win32 security is meant to go into the wineserver (if ever), so the model is already close to what you want, I guess.
Not too far by the sounds of things - still if the PE-loaded process is the one creating and controlling windows there become permission difficulties running it as a "nobody" user (and assembly hacks in the PE-executables could still try to do nasty crap in an anti-wine fashion if it has rights to your X-server). But at least this seems to provide for file-system and network policy enforcement by the wineserver process.
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?
Maybe some, but no fundamental ones, I think. Any such could probably easily be rewritten.
Cool.
What do you mean? No PE apps can link straight to glibc. Only Unix-implemented DLLs (like the Wine ones) can link to it. The problem
Ah, this had been my question. It seemed otherwise from the earlier post I had seen. I'm glad this is the case - you need to use virus-style hacks if you want your PE app to bypass (or corrupt) the interfaces provided by Wine libraries.
is rather that glibc will still be loaded into the process's *address space*, and thus a bad app could then get to it by searching for it in memory or get to it through the Wine builtin DLLs.
I understand the memory-scanning possibilities (just being able to find and corrupt wine-sensitive data is enough). However, if you sandbox those wine processes as a "nobody" user anyway, then any genuine attempts to bypass the wineserver-enforce policies would become a lot more difficult, ie. you'd be restricted to communicating with the wineserver and trying to convince it to do your nasty stuff for you. This is about the same problem as writing nasty code for MS windows. Moreover, the PE-loaded app doesn't get to execute its own code in the wineserver does it? If so, there's some merit to the approach David suggested.
So essentially I guess we could specify, for example, that no wine-loaded application has access to "F:" unless it is enabled in the wine command-line arguments? Eg.
wine --config-section=enable-F-home C:\...
where 'enable-F-home' could be a section in the config file specifying to map F: to $HOME?
IIUC, the answer to my PE-linkage question means the wineserver can enforce such rules unless the PE app uses "nasty" workarounds (eg. memory scanning assembly hacks)? The other answer you gave me suggests that if the PE apps could run in "nobody"-jailed processes, then there is even some protection against nasty workarounds (ie. the file-system and network policies become more genuinely, and less "voluntarily", secure)?
Cheers, Geoff