If you've read the recent mailing list posts dating up to a few weeks back I think, there have been some cases. But like everyone said, the fact the malware would even run in itself is almost bittersweet. It is bug-for-bug though so you can't just do that. Possibly an 'msconfig' like thing would be more realistic you know where you control (in a poor poor pooooooor way,) what runs at startup. yo ucould even go as far as to show the programs in the gnome-sessions program or the kde equivilent, thought that would be a pain (though cool.)
On 2/12/07, John Smith <[EMAIL PROTECTED]> wrote:
Part of my confusion what usage pattern is contracting malware on wine in the first place On 2/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > On 2/12/07, James Hawkins <[EMAIL PROTECTED]> wrote: > > On 2/11/07, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > > On 2/11/07, Misha Koshelev <[EMAIL PROTECTED]> wrote: > > > > Hi everybody, > > > > > > > > Thanks for your suggestions. I just posted a new patch on > wine-patches > > > > where I tried to incorporate these and now it does the following > (in > > > > addition to my previous patch which just started items in the > StartUp > > > > folder): > > > > > > > > - When wineboot finds a file that it wants to start in the StartUp > > > > folder, it asks the user whether he wants to run the program. His > > > > options are: Always, Yes, No (default), and Never. > > > > - If he selects Yes the program is run, if he select No it is not. > > > > - If he selects Always or Never, I create a registry key in: > > > > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full > pathname > > > > of the program and the value "always" or "never." When wineboot > sees > > > > this program in the StartUp folder it checks this key, and if it > is > > > > set it performs the appropriate action. > > > > > > > > What do you guys think? If you like the system, it would be pretty > easy > > > > to incorporate this into the run key running as well (which are > > > > currently just run without any user confirmation)? > > > > > > This sounds almost perfect. I think the counterpoint raised by > James > > > Hawkins would be adequately addressed by adding a winecfg option as > > > follows: > > > > > > Startup items behavior: > > > (*) Silently allow <-- This is "bug-for-bug > compatibility" > > > ( ) Ask <-- Most computer-savvy folks > would want this > > > ( ) Silently block > > > ( ) Block and notify me > > > > > > > This is unnecessarily complicated, and i really doubt anything like > > this would ever make it into the Wine tree. > > > > > Perhaps this should be independently set for each kind of startup > item > > > (startmenu\programs\startup, registry run key, profile settings, > etc), > > > but I think that's not really necessary. > > > > > > Also, I would suggest that the list of approved start items be > stored > > > outside of winespace, so that malware can't bypass the protection by > > > setting the key. Of course, really nasty stuff could still call > into > > > Linux, but that would require some hybrid system that was aware of > the > > > ELF dynamic loader in order to not fall afoul of address space > > > randomization. > > > > > > Ultimately I think wine is about more than just running > > > Windows-compatible programs without the Microsoft tax. It's about > > > running those programs without ceding control of your computer to an > > > untrustworthy party. We don't want the limitations that Windows > > > imposes... true bug-for-bug compatibility would mean only being able > > > > to access files on a FAT or NTFS partition, but I don't hear anyone > > > advocating for that kind of crippling behavior. > > > > > > > What? Wine has nothing to do with which file system your files reside > > > on. > You advocated that wine aim for working exactly like Windows, no less > and no more, rather than deviating in user-configurable ways to > enhance the user's control over his own system. Maybe while we're at > it, wine should have the bug which allows certain software to prevent > screen grabs. No, I think defeating DRM to enable fair use is > perfectly reasonable, and there are some bugs which should be fixed. > Should wine try to patch remote exploits at the exact same rate as > windowsupdate.com? That would be also be required for true > bug-for-bug compatibility. After all, someone properly authorized > might be using that backdoor to reboot their webfarm remotely -- not! > > There are things that are wrong in a theoretical sense (i.e. the > Pentium floating-point bug), or misclassification of Unicode > characters, which some programs might reasonably depend on. And then > there are things that are wrong from a practical engineering > perspective, like software taking away the user's choice to not run > it, which the mere fact that a program depends on it makes it malware. > > > Asking if you want to run every file set for startup in wineboot > > every single time is crippling behavior, not to mention annoying. UAC > > anyone? If you're so worried about this "malware", create a reduced > > privileges account just for Wine. > > That's the point of a "remember my choice" or "Yes/No/Always/Never" > option on the prompt which appears when the winecfg option is ask... > > Reduced privileges do little or nothing to prevent network abuse (open > spam relay and the like). > > > > > > > > > > > Thanks > > > > Misha > > > > > > > > p.s. please please please anyone who is familiar with IShellFolder > if > > > > you could look over those parts and just say yes it looks good > that > > > > would make me feel better. I think it is correct but really an > expert's > > > > opinion would be great. > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > James Hawkins > > > > >
-- Cheers, Bryan
