Log message: Try CreateProcess even if SHGetFileInfo fails so that we can launch Unix binaries.
Isn't that dangerous ? A windows program could gain access to some commands that shouldn't launch into normal windows.
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Thursday 10 October 2002 02:23 am, Sylvain Petreolle wrote:
Log message: Try CreateProcess even if SHGetFileInfo fails so that we can launch Unix binaries.
Isn't that dangerous ? A windows program could gain access to some commands that shouldn't launch into normal windows.
Certainly no less dangerous than allowing unix to launch windows programs ;)
(Just kidding, it's a legitimate question; I could imagine serious arguments on either side of this.)
"Sylvain Petreolle" spetreolle@yahoo.fr wrote:
Log message: Try CreateProcess even if SHGetFileInfo fails so that we can launch Unix binaries.
Isn't that dangerous ? A windows program could gain access to some commands that shouldn't launch into normal windows.
What are talking about? Don't you know how to set/tune security level in your Linux system? If you are *so* paranoid, just remove Wine completely from your system (along with all executables you've got in binary form; probably there is a trojan horse there too).
I will take an example : suppose you don't wan't windows programs to have access to the network. Today 'ping' requests doesn't work unless you're root, but the part that detects Internet connections returns always 'LAN connection'.
With this patch, a script can ask : ping something. Even if ping.exe is not there, CreateProcess will allow /bin/ping. This will work, as it's found and allowed for a normal unix user.
What are talking about? Don't you know how to set/tune security level in your Linux system? If you are *so* paranoid, just remove Wine completely from your system (along with all executables you've got in binary form; probably there is a trojan horse there too).
-- Dmitry.
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Sylvain Petreolle spetreolle@yahoo.fr writes:
With this patch, a script can ask : ping something. Even if ping.exe is not there, CreateProcess will allow /bin/ping. This will work, as it's found and allowed for a normal unix user.
There is no way to prevent a Windows application running under Wine from doing everything a Unix application could do. Even if you don't let CreateProcess launch Unix programs the Windows app can always do a straight system call. If you want to avoid inadvertently running /bin/ping you can make sure /bin is not accessible from a DOS drive. But you can't prevent a malicious app from doing it.
On Thu, Oct 10, 2002 at 10:30:40AM -0700, Alexandre Julliard wrote:
There is no way to prevent a Windows application running under Wine from doing everything a Unix application could do. Even if you don't let CreateProcess launch Unix programs the Windows app can always do a straight system call
This leaves just two options for the paranoid: Don't run untrusted applications - yeah I know that comes as a surprise :-) or run Wine inside UserModeLinux.
Ciao Jörg
-- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
On Thursday 10 Oct 2002 4:43 pm, Joerg Mayer wrote:
On Thu, Oct 10, 2002 at 10:30:40AM -0700, Alexandre Julliard wrote:
There is no way to prevent a Windows application running under Wine from doing everything a Unix application could do. Even if you don't let CreateProcess launch Unix programs the Windows app can always do a straight system call
This leaves just two options for the paranoid: Don't run untrusted applications - yeah I know that comes as a surprise :-) or run Wine inside UserModeLinux.
Or run it as a different user? Wine doesn't run a virtual machine, so you can't prevent running code (ie. whether it was loaded by wine or not) from doing anything that the user it's running as could do. Therefore, logically, the only rules that wine-loaded win32 code can't break are the same rules that no other program running as the same user can't break. So the way I see it there's no logical argument for putting restrictive rules into WINE that only make something *potentially* useful more difficult (and a lot less elegant) to do. In fact it could be very useful, especially for people wanting to mix "shell"-like tools which are in some cases native to win32 (eg. "cl.exe" or "somewebserver.exe") or native to unix (eg. "gmake" and "/etc/init.d/w32server", respectively).
Curiously, I see an analogy with comparing the quality of two kind of systems I've used before. System type A can only run binary/linked executables. System type B can run binary/linked executables *and* can also "run" text scripts by transparently invoking interpreter executables to interpret/compile/run the script contents - moreover, these linked executables and the scripts *can call each other*. [:-) I've used both type of systems often and I know that I prefer type B. In fact there's this cool app called WINE that works with systems of type B that allows you to run a *third* category of programs; those executables that were linked to run solely in system type A! Maybe I could turn my argument/opinion into a recursive tautology ...? "WINE make sense" iff "win32 and native binaries can interact" QED
:-)
Cheers, Geoff
-
Alexandre Julliard -
Dmitry Timoshkov -
Geoff Thorpe -
Greg Turner -
Joerg Mayer -
Sylvain Petreolle