Le ven 01/11/2002 à 11:27, Geoff Thorpe a écrit :
Hi there,
[snip]
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.
No. Just launch a Winelib app from the PE (it must be permissible to do so), and that Winelib app then has access to glibc and friends, and can act as a gateway between the main app and the outside (the sandbox) world. That app could be meant as an "enhancement" or "workaround" when running under Wine (thus not affecting normal Windows operation), but still have a "bug" which can do nasty things.
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?
Remember (from the thread on 0.8.0 feature list) that the config file should be merged completely in the registry, with a control-panel like app to aaply changes. So at least that app will need to be able to access it read/write.
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)?
Is it even possible to switch to the nobody user without having higher priviledges beforehand? I thought you needed to be launched by root (or SUID root, etc.) to switch to nobody, since it can't login (su, ssh, etc.)
Cheers, Geoff
-- Geoff Thorpe geoff@geoffthorpe.net http://www.geoffthorpe.net/
Just my 0.02 $ (yes, $ after. Do you say "dollar 3.56"? Neither do we in French :)
Vincent