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.
On 2/11/07, Misha Koshelev mk144210@bcm.tmc.edu 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.
richardvoigt@gmail.com 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
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:
richardvoigt@gmail.com 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
Felix Nawothnig wrote:
richardvoigt@gmail.com 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.
On Sunday 11 February 2007 06:49:58 pm richardvoigt@gmail.com 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.
What prevents malicious programs from writing this registry key on their own?
On 2/11/07, Chris Robinson chris.kcat@gmail.com wrote:
On Sunday 11 February 2007 06:49:58 pm richardvoigt@gmail.com 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.
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 chris.kcat@gmail.com wrote: On Sunday 11 February 2007 06:49:58 pm richardvoigt@gmail.com 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
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 chris.kcat@gmail.com wrote: On Sunday 11 February 2007 06:49:58 pm richardvoigt@gmail.com 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
On 2/11/07, richardvoigt@gmail.com richardvoigt@gmail.com wrote:
On 2/11/07, Misha Koshelev mk144210@bcm.tmc.edu 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.
On 2/12/07, James Hawkins truiken@gmail.com wrote:
On 2/11/07, richardvoigt@gmail.com richardvoigt@gmail.com wrote:
On 2/11/07, Misha Koshelev mk144210@bcm.tmc.edu 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
Part of my confusion what usage pattern is contracting malware on wine in the first place
On 2/12/07, richardvoigt@gmail.com richardvoigt@gmail.com wrote:
On 2/12/07, James Hawkins truiken@gmail.com wrote:
On 2/11/07, richardvoigt@gmail.com richardvoigt@gmail.com wrote:
On 2/11/07, Misha Koshelev mk144210@bcm.tmc.edu 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
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 xixsimplicityxix@gmail.com wrote:
Part of my confusion what usage pattern is contracting malware on wine in the first place
On 2/12/07, richardvoigt@gmail.com richardvoigt@gmail.com wrote:
On 2/12/07, James Hawkins truiken@gmail.com wrote:
On 2/11/07, richardvoigt@gmail.com < richardvoigt@gmail.com> wrote:
On 2/11/07, Misha Koshelev mk144210@bcm.tmc.edu 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
On 2/12/07, richardvoigt@gmail.com richardvoigt@gmail.com 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.
On 2/12/07, James Hawkins truiken@gmail.com wrote:
On 2/12/07, richardvoigt@gmail.com richardvoigt@gmail.com 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.
richardvoigt@gmail.com 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
-
Bryan Haskins -
Chris Robinson -
Felix Nawothnig -
James Hawkins -
John Smith -
Misha Koshelev -
richardvoigt＠gmail.com -
Vitaliy Margolen