On Saturday 26 October 2002 18.01, Eric Pouech wrote: > > Well for now there are not much Linux viruses around. It is possible to > > write an antivirus program (I have not heard of any yet) for Linux/Unix. > > if antivirus check for a signature, it should find it. it would be more > difficult for polyforms virii of course. > As of today, I don't think that people willing to write virii for > (against) Linux would use wine as their insertion media > You never know that the future holds. I can think of atleast one big company that want the death to Linux and Wine, its located in Redmond somewhere :-) > > And > > there are antivirus programs for Windows. But how do you check for > > viruses that directly affects the Linux/Unix environment embedded > > within a Windows app? I believe running windows apps in wine should be > > trusted the same way as enabling java in a web browser. > > there are some validity checks against the PE (file format). however, > wine > doesn't provide a sandbox. intercepting linux syscalls isn't enough > you need also to prevent : > 1/ read/write to wine memory (which would trigger some other nice side > effects) > 2/ read/write of local files (which isn't allowed for java in web > browser by default...) > 3/ know if a requested operation (syscall, win32 api call) is malicious > or not > > so wine will not protect users from windows programs > > the best thing to do (see some recent discussion on wine-devel on this > topic) is to limit the part of the disk wine will be allowed to > read/write to > > > Has an int 0x80 any purpose in Windows environment? > > under dos it sure has (don't have Ralf Brown list handy) > > > > > Cant you fix this with ptrace? > > > > Are you really sure? > > you will need to: > 1/ know which part of memory is calling (wine DLLs vs program exec vs > loaded DLLs) [regular windows API must be allowed to call linux > syscalls] I was told direct syscalls were only made through lovest level dlls, like ntdll,and from whithin dos/16 bit system. Whats this? > 2/ allow disallow the traps you want Why disallow interupt traps? > 3/ and because of the point 1 above, this will not be of any protection. > > for example, look at the following scheme: > 1/ get the address of the implementation of an API in wine > 2/ call Win32 API to allow write access to this part of memory > 3/ modify the code the make the linux syscall you want > 4/ call in this API. > > of course, you could in the ptrace code check for CRC of memory (or > calling page), but I wouldn't dare to use the final performance of such > a beast > > if you have enough time to loose on this, feel free to do it > > A+ I must admit I dont have a percent of your knowledge about the Wine and Windows architectures, so I have a hard time understanding why this is needed, and if therfore if its because of the way Wine is currently working or the way Windows calling is made. Imagine you write and ownership protect the trusted low level dlls (the ones that are supposed to be allowed syscalls). Would it not be possible to trace every Wine process for interupts and check if its originates from the lowlevel dlls? Checking the adress where interupt was is in the memory range of the loaded ntdll, to allow or disallow the call. Wouldnt that work? //Peter _______________________________________________ wine-users mailing list wine-users@winehq.com http://www.winehq.com/mailman/listinfo/wine-users
