Re: wineboot: Start items in StartUp folder on boot, includes security measures.
[EMAIL PROTECTED] wrote: And I have never advocated for putting this in the registry, my suggestion has always been to store these settings in a file outside the .wine/drive_c jail area that is accessbile via wine's Win32 API. Wine is *not* a sandbox. Any .exe run can make use of native (Linux) syscalls as it wants. Felix
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
On 2/12/07, James Hawkins <[EMAIL PROTECTED]> wrote: On 2/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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. > Right. That's the purpose of Wine. You'd know that if you were a developer on this project. You'll get there a lot faster by contributing to colinux (www.colinux.org) instead. > Maybe while we're at > it, wine should have the bug which allows certain software to prevent > screen grabs. > I don't know of any apps that depend on this behavior, so that's not likely to happen. Any DRM-enabled media player... which you would have understood if you looked at my next comment! > 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? > Since we have completely different code bases, I don't see how we can fix their code in our tree. You misunderstood me completely, I'm beginning to wonder if you're doing so intentionally. To maintain "bug for bug compatibility", then when an exploit is discovered, wine won't be able to release a patch until after Microsoft has done so, because to do so earlier would be to implement functionality that doesn't match WIndows, breaking compatibility. > 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. > Are you a software engineer? From a practical engineering perspective, adding this option adds unnecessary complication to the code base and increases the chances for bugs. This is exactly what I consider this sort of thing quite necessary, I would implement that function on Windows if it was possible without totally replacing all the security code (processing of Start menu/Programs/Startup and HKLM/Software/.../Run can be turned off, but group policy start items can't be disabled in any way that I'm aware of). UAC does, and no competent engineer thinks UAC is a good thing, or that it adds any amount of security. This "malware" that you're so UAC does add security, but the interface is horrid. It's really the same idea as Linux's don't-login-as-root, except that with linux you don't necessarily have to use sudo and type a password for every process you want to run elevated, there's suid, sudo remembers your credentials for a short while, you can open an elevated shell, etc. I think UAC has some of the same capability between signed manifests in place of suid and you can probably run an elevated shell there as well. afraid of can just write over that registry entry. I don't run Vista, but my understanding is that you can't permanently approve a particular program to run elevated, the question reappears every single time. Giving the user a per-program "Remember my answer" option improves the user experience so much it's not even comparable. And I have never advocated for putting this in the registry, my suggestion has always been to store these settings in a file outside the .wine/drive_c jail area that is accessbile via wine's Win32 API. If this entry defaults to "Always" or "Never", then the users won't even know that the option exists, and that's one more piece of information that we'll have to broadcast and answer questions about. So the best thing would be to set "Ask" as the installation default, and in addition to the "Yes/No/Always/Never" buttons on the prompt, provide a link to the winecfg page where the default is configured. > Reduced privileges do little or nothing to prevent network abuse (open > spam relay and the like). > If you're running executables that are going to add themselves to AutoStart, the fact that they might run again is the least of your concerns. While I agree 100%, stopping the malware from running itself after a reboot is still a very good thing. How useful would chroot be if the chrooted programs could set up autostart items or cron jobs without the admin's approval? Not nearly as much as it is now.
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
On 2/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: 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. Right. That's the purpose of Wine. You'd know that if you were a developer on this project. Maybe while we're at it, wine should have the bug which allows certain software to prevent screen grabs. I don't know of any apps that depend on this behavior, so that's not likely to happen. 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? Since we have completely different code bases, I don't see how we can fix their code in our tree. 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. Are you a software engineer? From a practical engineering perspective, adding this option adds unnecessary complication to the code base and increases the chances for bugs. This is exactly what UAC does, and no competent engineer thinks UAC is a good thing, or that it adds any amount of security. This "malware" that you're so afraid of can just write over that registry entry. > 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... If this entry defaults to "Always" or "Never", then the users won't even know that the option exists, and that's one more piece of information that we'll have to broadcast and answer questions about. Reduced privileges do little or nothing to prevent network abuse (open spam relay and the like). If you're running executables that are going to add themselves to AutoStart, the fact that they might run again is the least of your concerns. -- James Hawkins
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
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 pooor 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 i
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
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 >
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
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
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
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. 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. > > 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
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
On Sun, 2007-02-11 at 23:49 -0600, John Smith wrote: > What prevents malicious programs from writing this registry key on > their own? > > On 2/11/07, Chris Robinson <[EMAIL PROTECTED]> wrote: > On Sunday 11 February 2007 06:49:58 pm [EMAIL PROTECTED] > wrote: > > This sounds almost perfect. > > What would stop the program from adding the registry key > itself when placing > the item in the startup folder, or wherever else? > > > I think the counterpoint raised by James > > Hawkins would be adequately addressed by adding a winecfg > option as > > follows: > > Sounds like it's just asking if it should ask. > > I'm not really sure what you could do as a user that a program > couldn't just > override and do itself. Besides, users might not know whether > what's being > installed into an auto-start key/folder is necessary, deny it > for "safety > concerns", and have a broken installation. > I think the bigger security issue to be made is that until wine default behavior is not to set up the user's home directory in a writeable way as the Z: drive there is really no way to store any settings in any user-writable file without having malware being able to change if it wanted to and was written specifically for wine (please correct me if I am wrong). So I believe that, given this state, securing Wine from malware written for Windows (which most is) and not specifically for Wine is the best we can do. Misha >
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
On Sun, 2007-02-11 at 23:49 -0600, John Smith wrote: > What prevents malicious programs from writing this registry key on > their own? > > On 2/11/07, Chris Robinson <[EMAIL PROTECTED]> wrote: > On Sunday 11 February 2007 06:49:58 pm [EMAIL PROTECTED] > wrote: > > This sounds almost perfect. > > What would stop the program from adding the registry key > itself when placing > the item in the startup folder, or wherever else? > > > I think the counterpoint raised by James > > Hawkins would be adequately addressed by adding a winecfg > option as > > follows: > > Sounds like it's just asking if it should ask. > > I'm not really sure what you could do as a user that a program > couldn't just > override and do itself. Besides, users might not know whether > what's being > installed into an auto-start key/folder is necessary, deny it > for "safety > concerns", and have a broken installation. > > Yes, I will admit a program can just write this registry key and have itself run. My assumption is that most malware is currently written for Windows and not specifically for Wine, and thus such programs generally would not have any reason to write such a key. I think if malware really wanted to run _specifically_ on Wine it would be pretty easy to do with or without my patch, for example, overwrite a key system DLL and then just set the appropriate registry key so Wine uses the "native DLL" that the malware program has put. I think the "security" of my patch is based on the fact that most malware programs are written for Windows and I think if we start seeing Wine-specific malware we are going to have to develop a lot more security in a lot of places. Misha
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
What prevents malicious programs from writing this registry key on their own? On 2/11/07, Chris Robinson <[EMAIL PROTECTED]> wrote: On Sunday 11 February 2007 06:49:58 pm [EMAIL PROTECTED] wrote: > This sounds almost perfect. What would stop the program from adding the registry key itself when placing the item in the startup folder, or wherever else? > I think the counterpoint raised by James > Hawkins would be adequately addressed by adding a winecfg option as > follows: Sounds like it's just asking if it should ask. I'm not really sure what you could do as a user that a program couldn't just override and do itself. Besides, users might not know whether what's being installed into an auto-start key/folder is necessary, deny it for "safety concerns", and have a broken installation.
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
On Sunday 11 February 2007 06:49:58 pm [EMAIL PROTECTED] wrote: > This sounds almost perfect. What would stop the program from adding the registry key itself when placing the item in the startup folder, or wherever else? > I think the counterpoint raised by James > Hawkins would be adequately addressed by adding a winecfg option as > follows: Sounds like it's just asking if it should ask. I'm not really sure what you could do as a user that a program couldn't just override and do itself. Besides, users might not know whether what's being installed into an auto-start key/folder is necessary, deny it for "safety concerns", and have a broken installation.
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
James Hawkins wrote: > On 2/11/07, Misha Koshelev <[EMAIL PROTECTED]> wrote: >> Ok, thanks to everybody's responses on the wine-devel list. Here is my >> new version of this patch. It starts the items in the StartUp folder >> like Windows does (again, if anybody who knows about IShellFolder will >> look over my code that would be great :) I tested it and it works for >> the Vector NTI installer, but I would really like to have an expert's >> opinion on whether it is missing osmething). There were a lot of >> comments on wine-devel about malware using this system to start itself >> so here is what I added: >> >> To me it seems like this would be enough to prevent malware from using >> this system because the user could just click no or never. Also, someone >> pointed out that wineboot already runs quite a lot of other RUN registry >> keys that can be used for malware, and currently there is no system for >> these keys like the one I made for startup. Any comments will be >> appreciated. Thanks. >> > > These anti-malware changes are unnecessary. We implement Wine to be > bug-for-bug compatible with Windows. Windows doesn't ask this Then you will have to implement all the required functionality to allow anti-malware programs to function properly. Until then, Wine have to have some solutions to prevent nasty things to run on Wine. The excuse "bug-for-bug" will not cut it here! If you want that - you should not have ever switched to Linux in the first place. Vitaliy.
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
Felix Nawothnig wrote: > [EMAIL PROTECTED] wrote: >> This sounds almost perfect. I think the counterpoint raised by James >> Hawkins would be adequately addressed by adding a winecfg option as >> follows: > > Since we want winecfg to be gone in the long-term a registry key alone Who said that? Or you planning on implementing a winecfg replacement yet again? Vitaliy.
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
Ok, I sent out a patch with this fix to wine-patches. Now the
HKEY_CURRENT_USER\Software\Wine\StartupItems key can be set to
"always" which will make all items always run. Otherwise, previous
behavior with asking/keys for each individual items will occur.
Misha
On Mon, 2007-02-12 at 04:14 +0100, Felix Nawothnig wrote:
> [EMAIL PROTECTED] wrote:
> > This sounds almost perfect. I think the counterpoint raised by James
> > Hawkins would be adequately addressed by adding a winecfg option as
> > follows:
>
> Since we want winecfg to be gone in the long-term a registry key alone
> would probably do fine.
>
> Felix
From 7465a6f5e695a33670343cd959fca3fbf763899a Mon Sep 17 00:00:00 2001
From: Misha Koshelev <[EMAIL PROTECTED]>
Date: Sun, 11 Feb 2007 21:41:51 -0600
Subject: wineboot: Start items in StartUp folder on boot, includes security
measures.
---
programs/wineboot/En.rc | 36 +++
programs/wineboot/Makefile.in |5 +
programs/wineboot/wineboot.c | 222 +
programs/wineboot/wineboot.h | 21
programs/wineboot/wineboot.rc | 26 +
5 files changed, 307 insertions(+), 3 deletions(-)
diff --git a/programs/wineboot/En.rc b/programs/wineboot/En.rc
new file mode 100644
index 000..286b03c
--- /dev/null
+++ b/programs/wineboot/En.rc
@@ -0,0 +1,36 @@
+/*
+ * Wine Boot
+ * English Language Support
+ *
+ * Copyright (c) 2007 Misha Koshelev.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
+ */
+
+LANGUAGE LANG_ENGLISH, SUBLANG_DEFAULT
+
+Run_Confirmation_Dialog DIALOG 100, 200, 300, 70
+STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION
+CAPTION "Simulating Windows Boot"
+FONT 8, "MS Shell Dlg"
+{
+ LTEXT "The following program would like to be run:", -1, 20, 10, 260, 12
+ LTEXT "Program name here", ID_PROGRAM, 20, 22, 260, 12
+ LTEXT "Would you like to run the program?", -1, 20, 34, 260, 12
+ PUSHBUTTON "Always", ID_ALWAYS, 40, 50, 50, 14, WS_GROUP | WS_TABSTOP
+ PUSHBUTTON "Yes", IDYES, 100, 50, 50, 14, WS_GROUP | WS_TABSTOP
+ DEFPUSHBUTTON "No", IDNO, 160, 50, 50, 14, BS_DEFPUSHBUTTON | WS_GROUP |
WS_TABSTOP
+ PUSHBUTTON "Never", ID_NEVER, 220, 50, 50, 14, WS_GROUP | WS_TABSTOP
+}
diff --git a/programs/wineboot/Makefile.in b/programs/wineboot/Makefile.in
index 08c27a5..7437cab 100644
--- a/programs/wineboot/Makefile.in
+++ b/programs/wineboot/Makefile.in
@@ -4,12 +4,15 @@ SRCDIR= @srcdir@
VPATH = @srcdir@
MODULE= wineboot.exe
APPMODE = -mconsole
-IMPORTS = version user32 advapi32 kernel32
+IMPORTS = version user32 advapi32 kernel32 shell32 shlwapi
+EXTRALIBS = -luuid
C_SRCS = \
shutdown.c \
wineboot.c
+RC_SRCS = wineboot.rc
+
@MAKE_PROG_RULES@
@DEPENDENCIES@ # everything below this line is overwritten by make depend
diff --git a/programs/wineboot/wineboot.c b/programs/wineboot/wineboot.c
index 1434003..ba973cf 100644
--- a/programs/wineboot/wineboot.c
+++ b/programs/wineboot/wineboot.c
@@ -37,7 +37,7 @@
* - HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
(all, synch)
* - HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run (all,
asynch)
* - HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run (all,
asynch)
- * - Startup folders (all, ?asynch?, no imp)
+ * - Startup folders (all, ?asynch?)
* - HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce (all,
asynch)
*
* Somewhere in there is processing the RunOnceEx entries (also no imp)
@@ -63,6 +63,14 @@ #endif
#include
#include
+#define COBJMACROS
+#include
+#include
+#include
+#include
+
+#include "wineboot.h"
+
WINE_DEFAULT_DEBUG_CHANNEL(wineboot);
#define MAX_LINE_LENGTH (2*MAX_PATH+2)
@@ -616,6 +624,214 @@ static int ProcessWindowsFileProtection(
return 1;
}
+/* A dialog box handler for the run confirmation dialog box. */
+static INT_PTR rcd_Setup(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
+{
+HWND hWndDesktop;
+RECT rcDesktop, rc;
+LPCWSTR wProgram;
+
+switch(uMsg)
+{
+ case WM_INITDIALOG:
+ /* Center the dialog box */
+ hWndDesktop = Get
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
[EMAIL PROTECTED] wrote: This sounds almost perfect. I think the counterpoint raised by James Hawkins would be adequately addressed by adding a winecfg option as follows: Since we want winecfg to be gone in the long-term a registry key alone would probably do fine. Felix
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
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 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. 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.
wineboot: Start items in StartUp folder on boot, includes security measures. [with the patch]
I forgot to include the patch, so here it is.
Misha
---
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)?
Thanks
Misha
From 47a35d8e5296a094b14b03d01ab001f90a60b50e Mon Sep 17 00:00:00 2001
From: Misha Koshelev <[EMAIL PROTECTED]>
Date: Sun, 11 Feb 2007 15:19:46 -0600
Subject: wineboot: Start items in StartUp folder on boot, includes security
measures.
---
programs/wineboot/En.rc | 36 +++
programs/wineboot/Makefile.in |5 +
programs/wineboot/wineboot.c | 201 +
programs/wineboot/wineboot.h | 21
programs/wineboot/wineboot.rc | 26 +
5 files changed, 286 insertions(+), 3 deletions(-)
diff --git a/programs/wineboot/En.rc b/programs/wineboot/En.rc
new file mode 100644
index 000..286b03c
--- /dev/null
+++ b/programs/wineboot/En.rc
@@ -0,0 +1,36 @@
+/*
+ * Wine Boot
+ * English Language Support
+ *
+ * Copyright (c) 2007 Misha Koshelev.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
+ */
+
+LANGUAGE LANG_ENGLISH, SUBLANG_DEFAULT
+
+Run_Confirmation_Dialog DIALOG 100, 200, 300, 70
+STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION
+CAPTION "Simulating Windows Boot"
+FONT 8, "MS Shell Dlg"
+{
+ LTEXT "The following program would like to be run:", -1, 20, 10, 260, 12
+ LTEXT "Program name here", ID_PROGRAM, 20, 22, 260, 12
+ LTEXT "Would you like to run the program?", -1, 20, 34, 260, 12
+ PUSHBUTTON "Always", ID_ALWAYS, 40, 50, 50, 14, WS_GROUP | WS_TABSTOP
+ PUSHBUTTON "Yes", IDYES, 100, 50, 50, 14, WS_GROUP | WS_TABSTOP
+ DEFPUSHBUTTON "No", IDNO, 160, 50, 50, 14, BS_DEFPUSHBUTTON | WS_GROUP |
WS_TABSTOP
+ PUSHBUTTON "Never", ID_NEVER, 220, 50, 50, 14, WS_GROUP | WS_TABSTOP
+}
diff --git a/programs/wineboot/Makefile.in b/programs/wineboot/Makefile.in
index 08c27a5..7437cab 100644
--- a/programs/wineboot/Makefile.in
+++ b/programs/wineboot/Makefile.in
@@ -4,12 +4,15 @@ SRCDIR= @srcdir@
VPATH = @srcdir@
MODULE= wineboot.exe
APPMODE = -mconsole
-IMPORTS = version user32 advapi32 kernel32
+IMPORTS = version user32 advapi32 kernel32 shell32 shlwapi
+EXTRALIBS = -luuid
C_SRCS = \
shutdown.c \
wineboot.c
+RC_SRCS = wineboot.rc
+
@MAKE_PROG_RULES@
@DEPENDENCIES@ # everything below this line is overwritten by make depend
diff --git a/programs/wineboot/wineboot.c b/programs/wineboot/wineboot.c
index 1434003..d4095aa 100644
--- a/programs/wineboot/wineboot.c
+++ b/programs/wineboot/wineboot.c
@@ -37,7 +37,7 @@
* - HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
(all, synch)
* - HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run (all,
asynch)
* - HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run (all,
asynch)
- * - Startup folders (all, ?asynch?, no imp)
+ * - Startup folders (all, ?asynch?)
* - HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce (all,
asynch)
*
* Somewhere in there is processing the RunOnceEx entries (also no imp)
@@ -63,6 +63,14 @@ #endif
#include
#include
+#define COBJMACROS
+#include
+#include
+#include
+#include
+
+#include "wineboot.h"
+
WINE_DEFAULT_DEBUG_CHANNEL(wineboot);
#define MAX_LINE_LENGTH (2*MAX_PATH+2)
@@ -616,6 +624,19
RE: wineboot: Start items in StartUp folder on boot, includes security measures.
Well, that is what I thought too, I sent out another patch that does not have these anti-security measures, but there were a lot of responses about them being necessary and someone marked the bug report as WILLNOTFIX. Anyhow, both patches have been sent to wine-patches and also are available in the bug report #7384, so I think Alexandre can choose one or the other. Anyone have any comments about the IShellFolder code or jus want to check it over and give me a yay or nay? It works for me, but I just wanted to check with an expert. Misha -Original Message- From: James Hawkins [mailto:[EMAIL PROTECTED] Sent: Sun 2/11/2007 4:09 PM To: wine-devel@winehq.org Cc: Koshelev, Misha Vladislavo Subject: Re: wineboot: Start items in StartUp folder on boot, includes security measures. On 2/11/07, Misha Koshelev <[EMAIL PROTECTED]> wrote: > Ok, thanks to everybody's responses on the wine-devel list. Here is my > new version of this patch. It starts the items in the StartUp folder > like Windows does (again, if anybody who knows about IShellFolder will > look over my code that would be great :) I tested it and it works for > the Vector NTI installer, but I would really like to have an expert's > opinion on whether it is missing osmething). There were a lot of > comments on wine-devel about malware using this system to start itself > so here is what I added: > > - 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. > > To me it seems like this would be enough to prevent malware from using > this system because the user could just click no or never. Also, someone > pointed out that wineboot already runs quite a lot of other RUN registry > keys that can be used for malware, and currently there is no system for > these keys like the one I made for startup. Any comments will be > appreciated. Thanks. > These anti-malware changes are unnecessary. We implement Wine to be bug-for-bug compatible with Windows. Windows doesn't ask this question, and Wine shouldn't either. It's not our policy to not implement portions of Windows that make it easier for malware to run. -- James Hawkins
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
On 2/11/07, Misha Koshelev <[EMAIL PROTECTED]> wrote: Ok, thanks to everybody's responses on the wine-devel list. Here is my new version of this patch. It starts the items in the StartUp folder like Windows does (again, if anybody who knows about IShellFolder will look over my code that would be great :) I tested it and it works for the Vector NTI installer, but I would really like to have an expert's opinion on whether it is missing osmething). There were a lot of comments on wine-devel about malware using this system to start itself so here is what I added: - 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. To me it seems like this would be enough to prevent malware from using this system because the user could just click no or never. Also, someone pointed out that wineboot already runs quite a lot of other RUN registry keys that can be used for malware, and currently there is no system for these keys like the one I made for startup. Any comments will be appreciated. Thanks. These anti-malware changes are unnecessary. We implement Wine to be bug-for-bug compatible with Windows. Windows doesn't ask this question, and Wine shouldn't either. It's not our policy to not implement portions of Windows that make it easier for malware to run. -- James Hawkins
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
It seems the patch itself got lost Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367
wineboot: Start items in StartUp folder on boot, includes security measures.
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)? 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.
Re: wineboot: Start items in StartUp folder on boot.
On 2/10/07, Jacob Alberty <[EMAIL PROTECTED]> wrote: Why not integrate this functionality into wineboot? That way if a user wants to completely deny the start-up folder they can just not add wineboot to the list of programs to be started on login, but if they want that functionality they can simply add wineboot to the list of programs for start up when they login? It would allow similar functionality to windows whilst still keeping it a separate system. I think everyone agrees that wineboot is where this functionality should be, if it's implemented at all? Well, part of my idea was that even if the configuration option is set to "silently deny", any option that was previously accepted with the don't ask again option checked (or Always in case wine has buttons for Never, Not This Time, Run This Time, Always) would still execute, which is rather different from totally disabling wineboot. Then you could presumably run wineboot explicitly or some helper program, in order to manage the entries. On 2/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On 2/10/07, David Lichterman <[EMAIL PROTECTED] > wrote: > > Stefan Dösinger wrote: > > > Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: > > >> Misha Koshelev wrote: > > >>> Hi, > > >>> > > >>> As you all may have noticed, I have been making quite a few patches > > >>> within the last two weeks (or at least quite a few when compared to zero > > >>> before then) because I had figured out that the Vector NTI program that > > >>> is quite important in molecular biologThis patch makes sure that wine > > >>> will start items in the StartUp folder > > >> IMHO this should not be fixed. > > >> > > >> I've seen lots and lots of malicious programs using this mechanism to > > >> start themselves. And even worse if installer uses this to restart > > >> itself. That means this installer might not work most of the time on > > >> windows. > > > Malicious programs can also write themselves to > > > HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not > > > see any advantage in implementing the Run key, but not the autostart folder. > > > > > > > > > > > > > > > > > I second that opinion. I do computer tech support (ie getting viruses > > and spy/malware off of windows) at my university and if there's a case > > for not implementing one of those two run at boot features, disabling > > the Run key would be the stronger since most, if not all malicious > > programs now use the run registry location as opposed to the Startup folder. > > > > It really comes down to the amount of power a user should have. Maybe > > require a gksu whenever an app tries to write something to that folder > > or that registry location? > > What a gksu? > > How about prompting the user during startup? > > e.g., "Start using command line ? Yes/No ([x] > Don't ask again" > Don't ask again items could either be stored as hash codes in a > configuration file outside the wine filesystem, or else by deleting > command/moving to a usual Unixy autostart location. > > This should be done for all startup programs, whether start menu or registry. > > It would be the best of both worlds, it works as expected for the user > without requiring them to give up control of their system. > > There could even be a winecfg option whether to prompt the user, > silently allow, automatically+loudly deny, or silently deny. > > >
Re: wineboot: Start items in StartUp folder on boot.
Why not integrate this functionality into wineboot? That way if a user wants to completely deny the start-up folder they can just not add wineboot to the list of programs to be started on login, but if they want that functionality they can simply add wineboot to the list of programs for start up when they login? It would allow similar functionality to windows whilst still keeping it a separate system. On 2/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: On 2/10/07, David Lichterman <[EMAIL PROTECTED]> wrote: > Stefan Dösinger wrote: > > Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: > >> Misha Koshelev wrote: > >>> Hi, > >>> > >>> As you all may have noticed, I have been making quite a few patches > >>> within the last two weeks (or at least quite a few when compared to zero > >>> before then) because I had figured out that the Vector NTI program that > >>> is quite important in molecular biologThis patch makes sure that wine > >>> will start items in the StartUp folder > >> IMHO this should not be fixed. > >> > >> I've seen lots and lots of malicious programs using this mechanism to > >> start themselves. And even worse if installer uses this to restart > >> itself. That means this installer might not work most of the time on > >> windows. > > Malicious programs can also write themselves to > > HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not > > see any advantage in implementing the Run key, but not the autostart folder. > > > > > > > > > > > I second that opinion. I do computer tech support (ie getting viruses > and spy/malware off of windows) at my university and if there's a case > for not implementing one of those two run at boot features, disabling > the Run key would be the stronger since most, if not all malicious > programs now use the run registry location as opposed to the Startup folder. > > It really comes down to the amount of power a user should have. Maybe > require a gksu whenever an app tries to write something to that folder > or that registry location? What a gksu? How about prompting the user during startup? e.g., "Start using command line ? Yes/No ([x] Don't ask again" Don't ask again items could either be stored as hash codes in a configuration file outside the wine filesystem, or else by deleting command/moving to a usual Unixy autostart location. This should be done for all startup programs, whether start menu or registry. It would be the best of both worlds, it works as expected for the user without requiring them to give up control of their system. There could even be a winecfg option whether to prompt the user, silently allow, automatically+loudly deny, or silently deny.
Re: wineboot: Start items in StartUp folder on boot.
On 2/10/07, David Lichterman <[EMAIL PROTECTED]> wrote: Stefan Dösinger wrote: > Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: >> Misha Koshelev wrote: >>> Hi, >>> >>> As you all may have noticed, I have been making quite a few patches >>> within the last two weeks (or at least quite a few when compared to zero >>> before then) because I had figured out that the Vector NTI program that >>> is quite important in molecular biologThis patch makes sure that wine >>> will start items in the StartUp folder >> IMHO this should not be fixed. >> >> I've seen lots and lots of malicious programs using this mechanism to >> start themselves. And even worse if installer uses this to restart >> itself. That means this installer might not work most of the time on >> windows. > Malicious programs can also write themselves to > HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not > see any advantage in implementing the Run key, but not the autostart folder. > > > > > I second that opinion. I do computer tech support (ie getting viruses and spy/malware off of windows) at my university and if there's a case for not implementing one of those two run at boot features, disabling the Run key would be the stronger since most, if not all malicious programs now use the run registry location as opposed to the Startup folder. It really comes down to the amount of power a user should have. Maybe require a gksu whenever an app tries to write something to that folder or that registry location? What a gksu? How about prompting the user during startup? e.g., "Start using command line ? Yes/No ([x] Don't ask again" Don't ask again items could either be stored as hash codes in a configuration file outside the wine filesystem, or else by deleting command/moving to a usual Unixy autostart location. This should be done for all startup programs, whether start menu or registry. It would be the best of both worlds, it works as expected for the user without requiring them to give up control of their system. There could even be a winecfg option whether to prompt the user, silently allow, automatically+loudly deny, or silently deny.
Re: wineboot: Start items in StartUp folder on boot.
Stefan Dösinger wrote: Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: Misha Koshelev wrote: Hi, As you all may have noticed, I have been making quite a few patches within the last two weeks (or at least quite a few when compared to zero before then) because I had figured out that the Vector NTI program that is quite important in molecular biologThis patch makes sure that wine will start items in the StartUp folder IMHO this should not be fixed. I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows. Malicious programs can also write themselves to HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not see any advantage in implementing the Run key, but not the autostart folder. I second that opinion. I do computer tech support (ie getting viruses and spy/malware off of windows) at my university and if there's a case for not implementing one of those two run at boot features, disabling the Run key would be the stronger since most, if not all malicious programs now use the run registry location as opposed to the Startup folder. It really comes down to the amount of power a user should have. Maybe require a gksu whenever an app tries to write something to that folder or that registry location? /2cents -Dave
Re: wineboot: Start items in StartUp folder on boot.
Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen: > Misha Koshelev wrote: > > Hi, > > > > As you all may have noticed, I have been making quite a few patches > > within the last two weeks (or at least quite a few when compared to zero > > before then) because I had figured out that the Vector NTI program that > > is quite important in molecular biologThis patch makes sure that wine > > will start items in the StartUp folder > > IMHO this should not be fixed. > > I've seen lots and lots of malicious programs using this mechanism to > start themselves. And even worse if installer uses this to restart > itself. That means this installer might not work most of the time on > windows. Malicious programs can also write themselves to HKLM/Software/Microsoft/Windows/Run, a key that wineboot reads. So I do not see any advantage in implementing the Run key, but not the autostart folder. pgp8o9FlD98yE.pgp Description: PGP signature
Re: wineboot: Start items in StartUp folder on boot.
I thought wine's goal was "bug for bug" with windows, for good or for ill. On 2/9/07, Misha Koshelev <[EMAIL PROTECTED]> wrote: On Fri, 2007-02-09 at 21:20 -0700, Vitaliy Margolen wrote: > Misha Koshelev wrote: > > Hi, > > > > As you all may have noticed, I have been making quite a few patches > > within the last two weeks (or at least quite a few when compared to zero > > before then) because I had figured out that the Vector NTI program that > > is quite important in molecular biologThis patch makes sure that wine > > will start items in the StartUp folder > IMHO this should not be fixed. > > I've seen lots and lots of malicious programs using this mechanism to > start themselves. And even worse if installer uses this to restart > itself. That means this installer might not work most of the time on > windows. > > Vitaliy. Well that is fair if that is the consensus. I did try the installer on a plain Win98 system and this restart does work for it there. Maybe have some kind of option to optionally do this or is that out of the question too? Thanks for the info. Misha
Re: wineboot: Start items in StartUp folder on boot.
On Fri, 2007-02-09 at 21:20 -0700, Vitaliy Margolen wrote: > Misha Koshelev wrote: > > Hi, > > > > As you all may have noticed, I have been making quite a few patches > > within the last two weeks (or at least quite a few when compared to zero > > before then) because I had figured out that the Vector NTI program that > > is quite important in molecular biologThis patch makes sure that wine > > will start items in the StartUp folder > IMHO this should not be fixed. > > I've seen lots and lots of malicious programs using this mechanism to > start themselves. And even worse if installer uses this to restart > itself. That means this installer might not work most of the time on > windows. > > Vitaliy. Well that is fair if that is the consensus. I did try the installer on a plain Win98 system and this restart does work for it there. Maybe have some kind of option to optionally do this or is that out of the question too? Thanks for the info. Misha
Re: wineboot: Start items in StartUp folder on boot.
Misha Koshelev wrote: > Hi, > > As you all may have noticed, I have been making quite a few patches > within the last two weeks (or at least quite a few when compared to zero > before then) because I had figured out that the Vector NTI program that > is quite important in molecular biologThis patch makes sure that wine > will start items in the StartUp folder IMHO this should not be fixed. I've seen lots and lots of malicious programs using this mechanism to start themselves. And even worse if installer uses this to restart itself. That means this installer might not work most of the time on windows. Vitaliy.
wineboot: Start items in StartUp folder on boot.
Hi,
As you all may have noticed, I have been making quite a few patches
within the last two weeks (or at least quite a few when compared to zero
before then) because I had figured out that the Vector NTI program that
is quite important in molecular biologThis patch makes sure that wine
will start items in the StartUp folder
(Programs) just like Windows. The reason this is necessary, well #1 this
is something Windows does that Wine doesn't do, but #2 this is required
by the Vector NTI installer (bug #7384), which installs necessary
dependencies (MDAC and about 6 other things) by installing one, then
placing a link to itself in StartUp, then rebooting. With this patch, it
will actually restart correctly, and in fact just running wine
installer.exe will actually successfully do the install from start to
finish (for the alternative to install this prior to this and a few
other patches, see my shell script
http://misha680.googlepages.com/InstallVectorNTI10.sh). There is still
the lack of JScript support which fails to install some things, but
that's about it.y (and freely available to academic researchers) can be
installed on Wine and run with quite little problem with a quite
complicated install script I made
http://misha680.googlepages.com/InstallVectorNTI10.sh). There was one
pretty significant bug, but after that I wanted to try to track down and
patch other bugs that forced the above script to be required. With the
exception of a pretty significant lack of JScript support in wine/MSI
which causes installation of quite a few files to fail (and thus still
require native jscript.dll and native MSI), this final patch I just sent
out makes the install work from start to finish, which is quite a change
from before.
I posted two patches earlier (a conformance test and a fix) that adds
path searching to shell link creation (which the conformance test shows
exists in Windows for a file like rundll32.exe that is not found in the
current directory), and if anyone has comments about those patches
please send them to me. My last patch ensures that this shelllink that
the Vector NTI installer creates every time it tries to restart (about
six or so times after every Microsoft component it installs that it
needs and comes with) will be executed, and in fact is meant to
reproduce the Windows behavior of starting items in the StartUp program
group on login that occurs in Windows. I am new to the whole
IShellFolder thing, though, and I tried to make it as proper as I could.
But I certainly feel that I would like to have someone more experience
to look at it.
Oh, and I just wanted to say a big thanks to Dan Kegel, James Hawkings,
Mike McCormack, and others who have helped me so far (not to mention
Alexandre Julliard for committing some of my patches).
Misha
From 446dbc9d3f961bff416e20b3504305763d145a78 Mon Sep 17 00:00:00 2001
From: Misha Koshelev <[EMAIL PROTECTED]>
Date: Fri, 9 Feb 2007 21:48:21 -0600
Subject: wineboot: Start items in StartUp folder on boot.
---
programs/wineboot/Makefile.in |3 +
programs/wineboot/wineboot.c | 92 +
2 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/programs/wineboot/Makefile.in b/programs/wineboot/Makefile.in
index 08c27a5..bf1b723 100644
--- a/programs/wineboot/Makefile.in
+++ b/programs/wineboot/Makefile.in
@@ -4,7 +4,8 @@ SRCDIR= @srcdir@
VPATH = @srcdir@
MODULE= wineboot.exe
APPMODE = -mconsole
-IMPORTS = version user32 advapi32 kernel32
+IMPORTS = version user32 advapi32 kernel32 shell32 shlwapi
+EXTRALIBS = -luuid
C_SRCS = \
shutdown.c \
diff --git a/programs/wineboot/wineboot.c b/programs/wineboot/wineboot.c
index 1434003..bda10b1 100644
--- a/programs/wineboot/wineboot.c
+++ b/programs/wineboot/wineboot.c
@@ -63,6 +63,12 @@ #endif
#include
#include
+#define COBJMACROS
+#include
+#include
+#include
+#include
+
WINE_DEFAULT_DEBUG_CHANNEL(wineboot);
#define MAX_LINE_LENGTH (2*MAX_PATH+2)
@@ -616,6 +622,88 @@ static int ProcessWindowsFileProtection(
return 1;
}
+/* Process items in the StartUp group of the user's Programs under the Start
Menu. Some installers put
+ * shell links here to restart themselves after boot. */
+static BOOL ProcessStartupItems()
+{
+BOOL ret = FALSE;
+HRESULT hr;
+int iRet;
+IMalloc *ppM = NULL;
+IShellFolder *psfDesktop = NULL, *psfStartup = NULL;
+LPITEMIDLIST pidlStartup = NULL, pidlItem;
+ULONG NumPIDLs;
+IEnumIDList *iEnumList = NULL;
+STRRET strret;
+WCHAR wszCommand[MAX_PATH];
+
+WINE_TRACE("Processing items in the StartUp folder.\n");
+
+hr = SHGetMalloc(&ppM);
+if (FAILED(hr))
+{
+ WINE_ERR("Couldn't get IMalloc object.\n");
+ goto done;
+}
+
+hr = SHGetDesktopFolder(&psfDesktop);
+if (FAILED(hr))
+{
+ WINE_ERR("Couldn't get desktop folder.\n");
+ goto do
