http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-... is an interesting report; all the malware he tried ran to at least some extent on wine.
One interesting bit of advice he gives at the end is
"Do not set the file association for Windows executables with Wine. This would enable running Windows executables in Wine by simply double clicking them."
I saw a patch floating by to turn this on by default recently. Maybe we should make it off by default, but easy to turn on...?
2009/2/24 Dan Kegel dank@kegel.com:
http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-... is an interesting report; all the malware he tried ran to at least some extent on wine.
One interesting bit of advice he gives at the end is
"Do not set the file association for Windows executables with Wine. This would enable running Windows executables in Wine by simply double clicking them."
I saw a patch floating by to turn this on by default recently. Maybe we should make it off by default, but easy to turn on...?
This would annoy all the people that the association targets. We can either make it easy to run all Windows apps (malware and legit) via file manager, or none at all.
Personally, I don't really care. I tend to run wine from a terminal anyway so I can watch the pretty fixmes. But if it was my decision, I'd probably err on the side of security.
Ben Klein shacklein@gmail.com wrote:
http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-...
"Do not set the file association for Windows executables with Wine. This would enable running Windows executables in Wine by simply double clicking them."
I saw a patch floating by to turn this on by default recently. Maybe we should make it off by default, but easy to turn on...?
This would annoy all the people that the association targets. We can either make it easy to run all Windows apps (malware and legit) via file manager, or none at all.
Yes, exactly. The default should be off, and it should be easy to turn on. - Dan
2009/2/23 Dan Kegel dank@kegel.com:
Ben Klein shacklein@gmail.com wrote:
http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-...
"Do not set the file association for Windows executables with Wine. This would enable running Windows executables in Wine by simply double clicking them."
I saw a patch floating by to turn this on by default recently. Maybe we should make it off by default, but easy to turn on...?
This would annoy all the people that the association targets. We can either make it easy to run all Windows apps (malware and legit) via file manager, or none at all.
Yes, exactly. The default should be off, and it should be easy to turn on.
- Dan
I disagree on this point. Is malware via Wine on Linux really a problem commonly affecting users? What happened to replicated Window's behavior bug for bug? User X might ask: double clicking an exe works in Windows why shouldn't it in Linux? Why should user X have to go through an extra step to do something on Linux than they would on Windows?
-Zach
2009/2/24 Zachary Goldberg zgold@bluesata.com:
2009/2/23 Dan Kegel dank@kegel.com:
Ben Klein shacklein@gmail.com wrote:
http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-...
"Do not set the file association for Windows executables with Wine. This would enable running Windows executables in Wine by simply double clicking them."
I saw a patch floating by to turn this on by default recently. Maybe we should make it off by default, but easy to turn on...?
This would annoy all the people that the association targets. We can either make it easy to run all Windows apps (malware and legit) via file manager, or none at all.
Yes, exactly. The default should be off, and it should be easy to turn on.
- Dan
I disagree on this point. Is malware via Wine on Linux really a problem commonly affecting users? What happened to replicated Window's behavior bug for bug? User X might ask: double clicking an exe works in Windows why shouldn't it in Linux? Why should user X have to go through an extra step to do something on Linux than they would on Windows?
Thing is, this is not something that's explicitly within Wine. It's desktop integration at best, and file manager-specific at worst. I'd say it doesn't fall under the heading of "bug-for-bug compatibility".
That's just me though. Comments from real Wine devs would be much more meaningful :)
2009/2/23 Ben Klein shacklein@gmail.com:
2009/2/24 Zachary Goldberg zgold@bluesata.com:
2009/2/23 Dan Kegel dank@kegel.com:
Ben Klein shacklein@gmail.com wrote:
http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-...
"Do not set the file association for Windows executables with Wine. This would enable running Windows executables in Wine by simply double clicking them."
I saw a patch floating by to turn this on by default recently. Maybe we should make it off by default, but easy to turn on...?
This would annoy all the people that the association targets. We can either make it easy to run all Windows apps (malware and legit) via file manager, or none at all.
Yes, exactly. The default should be off, and it should be easy to turn on.
- Dan
I disagree on this point. Is malware via Wine on Linux really a problem commonly affecting users? What happened to replicated Window's behavior bug for bug? User X might ask: double clicking an exe works in Windows why shouldn't it in Linux? Why should user X have to go through an extra step to do something on Linux than they would on Windows?
Thing is, this is not something that's explicitly within Wine. It's desktop integration at best, and file manager-specific at worst. I'd say it doesn't fall under the heading of "bug-for-bug compatibility".
That's just me though. Comments from real Wine devs would be much more meaningful :)
I interpret bug-for-bug compatibility to be more than just emulating the API bugs so apps run. Its about emulating the experience for users to be as close to expectations (set by Windows) as possible. Preventing them from double-clicking EXEs in the file manager without finding some arbitrary configuration option doesn't seem to be inline with this.
On Monday 23 February 2009 4:28:27 pm Zachary Goldberg wrote:
I interpret bug-for-bug compatibility to be more than just emulating the API bugs so apps run. Its about emulating the experience for users to be as close to expectations (set by Windows) as possible.
Can't say I agree with that. If a user wants the Windows experience, they should get Windows. Wine enables Windows apps to run on Linux and other Unix systems, not making Linux/Unix systems behave like Windows (IMO, it should make the Windows apps behave like Linux ones whenever possible).
Preventing them from double-clicking EXEs in the file manager without finding some arbitrary configuration option doesn't seem to be inline with this.
What about having to mark the exe as +x before Wine will load it? That's easilly doable frame any sane filemanager and provides a good level of safety.. and Wine already does a good job of making sure installed programs get +x.
What about having to mark the exe as +x before Wine will load it? That's easilly doable frame any sane filemanager and provides a good level of safety.. and Wine already does a good job of making sure installed programs get +x.
Wow it actually does, never noticed that up to now :O The problem would be with one of the more common use case: trying to start/install a program from an optical disc. The files will not be marked +x and the directories not be writable. This problem scenario is also rather specific to WiNE; not an issue for KDE f.e. whcih yesterday had a related change committed: .desktop files have to be marked as executable to be run on click now. Lively discussion about that is still ongoing on kde-core-devel.
Despite from the install-from-cdrom issue, few users that have (been) switched from windows to linux will know how to chmod +x a file, so wine would at least have to give them a hint (or even a button) to do it. But once it becomes easy, they will just get used to clicking it and not be consciously pondering if the action is safe or not. So while i think it'd make sense, i doubt it is a practical solution to require files to have the executable bit.
Maybe a better solution would be to introduce an optional dependency on ClamAV and tight integration with it - known malware could be filtered and distributors would have greater interest in contributing to continuous ClamAV signature updates..
regards marcel.
I think at best it should be up to the distribution to decide to enable additional security features, which is where most common users will get Wine from. Maybe display a warning on the download page?
(Gah, Reply to all, sorry Marcel.)
JL
On Tue, Feb 24, 2009 at 3:14 AM, Marcel Partap mpartap@gmx.net wrote:
What about having to mark the exe as +x before Wine will load it? That's easilly doable frame any sane filemanager and provides a good level of safety.. and Wine already does a good job of making sure installed programs get +x.
Wow it actually does, never noticed that up to now :O The problem would be with one of the more common use case: trying to start/install a program from an optical disc. The files will not be marked +x and the directories not be writable. This problem scenario is also rather specific to WiNE; not an issue for KDE f.e. whcih yesterday had a related change committed: .desktop files have to be marked as executable to be run on click now. Lively discussion about that is still ongoing on kde-core-devel.
Despite from the install-from-cdrom issue, few users that have (been) switched from windows to linux will know how to chmod +x a file, so wine would at least have to give them a hint (or even a button) to do it. But once it becomes easy, they will just get used to clicking it and not be consciously pondering if the action is safe or not. So while i think it'd make sense, i doubt it is a practical solution to require files to have the executable bit.
Maybe a better solution would be to introduce an optional dependency on ClamAV and tight integration with it - known malware could be filtered and distributors would have greater interest in contributing to continuous ClamAV signature updates..
regards marcel.
-- "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947)
Change the world! Vote: http://hfopi.org/vote-future
On Monday 23 February 2009 5:14:20 pm Marcel Partap wrote:
The problem would be with one of the more common use case: trying to start/install a program from an optical disc. The files will not be marked +x and the directories not be writable.
They're +x for me. They're not writable, but they don't need to be.
Maybe if you mount the disc with the noexec option the files aren't +x, but that's exactly what's supposed to happen.. prevent execution of programs on the mounted filesystem. The same issue would exist if the user had a CD with Linux programs on it. Why should Wine deliberately side-step such a security feature? Just because it's an exe loaded by Wine instead of loaded directly by the system shouldn't change what happens, IMO.
Despite from the install-from-cdrom issue, few users that have (been) switched from windows to linux will know how to chmod +x a file, so wine would at least have to give them a hint (or even a button) to do it.
I don't think Wine needs to bring up a button. It's easy enough to say to run chmod +x, and it's possible to say how to do it in the file manager (right- click the exe->Properties->Permissions, select that it's executable; I don't imagine it's too different across the default file managers).
If the user goes through the trouble of explicitly marking the exe as executable, then it's on their hands. Ignoring the executable flag or using a passive click-through dialog is an accident waiting to happen.
Maybe a better solution would be to introduce an optional dependency on ClamAV and tight integration with it - known malware could be filtered and distributors would have greater interest in contributing to continuous ClamAV signature updates..
I don't think it's Wine's place to save users from themselves. However, it should be Wine's place to honor basic system security options the user has set, and not double-guess them.
On Tuesday 24 February 2009 20:33:49 Chris Robinson wrote:
On Monday 23 February 2009 5:14:20 pm Marcel Partap wrote:
The problem would be with one of the more common use case: trying to start/install a program from an optical disc. The files will not be marked +x and the directories not be writable.
They're +x for me. They're not writable, but they don't need to be.
Maybe if you mount the disc with the noexec option the files aren't +x, but that's exactly what's supposed to happen.. prevent execution of programs on the mounted filesystem. The same issue would exist if the user had a CD with Linux programs on it. Why should Wine deliberately side-step such a security feature? Just because it's an exe loaded by Wine instead of loaded directly by the system shouldn't change what happens, IMO.
Despite from the install-from-cdrom issue, few users that have (been) switched from windows to linux will know how to chmod +x a file, so wine would at least have to give them a hint (or even a button) to do it.
I don't think Wine needs to bring up a button. It's easy enough to say to run chmod +x, and it's possible to say how to do it in the file manager (right- click the exe->Properties->Permissions, select that it's executable; I don't imagine it's too different across the default file managers).
If the user goes through the trouble of explicitly marking the exe as executable, then it's on their hands. Ignoring the executable flag or using a passive click-through dialog is an accident waiting to happen.
Maybe a better solution would be to introduce an optional dependency on ClamAV and tight integration with it - known malware could be filtered and distributors would have greater interest in contributing to continuous ClamAV signature updates..
I don't think it's Wine's place to save users from themselves. However, it should be Wine's place to honor basic system security options the user has set, and not double-guess them.
Those are not security options and were never intended to be.
The +x permission or noexec mount option are more convenient ways of disabling POSIX execution of files that are not supposed to be executable or on filesystems that does not support POSIX permissions.
My FAT partitions disable +x through file mode mount option since I don't want the kernel to attempt to identify and execute every unknown file I happen to open/click/hit enter. On those partitions there are no POSIX executables but plenty of Win32 ones - many of them shared between Windows and Wine.
On Tuesday 24 February 2009 3:46:53 pm Paul Chitescu wrote:
My FAT partitions disable +x through file mode mount option since I don't want the kernel to attempt to identify and execute every unknown file I happen to open/click/hit enter. On those partitions there are no POSIX executables but plenty of Win32 ones - many of them shared between Windows and Wine.
If you want to execute something (Wine or otherwise), why set -x? If you set a file to be -r, would you expect to read it in Wine, still? Or if it's -w, would you expect Wine apps to be able to write to it? Of course you wouldn't, so why should x be different?
If you require an exe to be +x, it becomes quite a bit more difficult to unintentionally run it. Unsolicited files do not get +x, thus it's impossible to execute them, accidentally or carelessly (sans the .desktop file issue that has come up, again, recently). If you ignore the +x, then all it takes is a mis-click on an email or some other simple mistake.
2009/2/25 Chris Robinson chris.kcat@gmail.com:
On Tuesday 24 February 2009 3:46:53 pm Paul Chitescu wrote:
My FAT partitions disable +x through file mode mount option since I don't want the kernel to attempt to identify and execute every unknown file I happen to open/click/hit enter. On those partitions there are no POSIX executables but plenty of Win32 ones - many of them shared between Windows and Wine.
If you want to execute something (Wine or otherwise), why set -x? If you set a file to be -r, would you expect to read it in Wine, still? Or if it's -w, would you expect Wine apps to be able to write to it? Of course you wouldn't, so why should x be different?
If you require an exe to be +x, it becomes quite a bit more difficult to unintentionally run it. Unsolicited files do not get +x, thus it's impossible to execute them, accidentally or carelessly (sans the .desktop file issue that has come up, again, recently). If you ignore the +x, then all it takes is a mis-click on an email or some other simple mistake.
"Unsolicited" files will get +x with default mount options on vfat/fat partitions, because ALL files on such partitions get +x this way.
I would at least like to see Wine respect noexec, if possible. I understand concerns about Wine respecting +x, due mainly to CD-based installers that may or may not have +x set on the files, but I think it would also be the *correct* thing to do. Possibly have some registry entry disable the +x check? This would be particularly useful on a per-application basis, allowing the construction of a whitelist.
On 25/02/09 01:54, Ben Klein wrote:
2009/2/25 Chris Robinsonchris.kcat@gmail.com:
On Tuesday 24 February 2009 3:46:53 pm Paul Chitescu wrote:
My FAT partitions disable +x through file mode mount option since I don't want the kernel to attempt to identify and execute every unknown file I happen to open/click/hit enter. On those partitions there are no POSIX executables but plenty of Win32 ones - many of them shared between Windows and Wine.
If you want to execute something (Wine or otherwise), why set -x? If you set a file to be -r, would you expect to read it in Wine, still? Or if it's -w, would you expect Wine apps to be able to write to it? Of course you wouldn't, so why should x be different?
If you require an exe to be +x, it becomes quite a bit more difficult to unintentionally run it. Unsolicited files do not get +x, thus it's impossible to execute them, accidentally or carelessly (sans the .desktop file issue that has come up, again, recently). If you ignore the +x, then all it takes is a mis-click on an email or some other simple mistake.
"Unsolicited" files will get +x with default mount options on vfat/fat partitions, because ALL files on such partitions get +x this way.
I would at least like to see Wine respect noexec, if possible. I understand concerns about Wine respecting +x, due mainly to CD-based installers that may or may not have +x set on the files, but I think it would also be the *correct* thing to do. Possibly have some registry entry disable the +x check? This would be particularly useful on a per-application basis, allowing the construction of a whitelist.
After all the discussion it still seems to me as if wine should neither relay on filesystems being mounted exec nor +x executables for now but instead really try and loosely integrate with the only FOSS anti-virus solution there is, clamav. Better than annoying one half of the users with non-runnable programs and giving the other half a false sense of security. regards.
On Tuesday 24 February 2009 4:54:26 pm Ben Klein wrote:
"Unsolicited" files will get +x with default mount options on vfat/fat partitions, because ALL files on such partitions get +x this way.
You have to mount a partition to get access to its files. A partition normally doesn't mount itself, unless you had previously set it up to do so. As such, you're actively trying to get the files.. they aren't just given to you without warning.
I would at least like to see Wine respect noexec, if possible. I understand concerns about Wine respecting +x, due mainly to CD-based installers that may or may not have +x set on the files, but I think it would also be the *correct* thing to do.
The (no)exec mount options are for specifying whether the executable bit is masked out or not. Filesystems like NTFS/FAT/ISO9660 do not have an executable bit (a shortcoming on their part), so it's always assumed to be on; the (no)exec options, in turn, control whether or not the the bit gets filtered out (ie. it determines whether the files get +x or not). To honor 'noexec' means Wine should honor +x.
If a user is trying to execute a program on a CD that's not +x, they mounted it wrong (or the CD was made wrong). I mean, assume it was a Linux program they were trying to run on a CD instead of a Windows one. If the file doesn't have +x, it won't run. There's no reason a Windows program executed with Wine should act differently than a Linux program executed directly.
2009/2/25 Chris Robinson chris.kcat@gmail.com:
On Tuesday 24 February 2009 4:54:26 pm Ben Klein wrote:
"Unsolicited" files will get +x with default mount options on vfat/fat partitions, because ALL files on such partitions get +x this way.
You have to mount a partition to get access to its files. A partition normally doesn't mount itself, unless you had previously set it up to do so. As such, you're actively trying to get the files.. they aren't just given to you without warning.
I would at least like to see Wine respect noexec, if possible. I understand concerns about Wine respecting +x, due mainly to CD-based installers that may or may not have +x set on the files, but I think it would also be the *correct* thing to do.
The (no)exec mount options are for specifying whether the executable bit is masked out or not. Filesystems like NTFS/FAT/ISO9660 do not have an executable bit (a shortcoming on their part), so it's always assumed to be on; the (no)exec options, in turn, control whether or not the the bit gets filtered out (ie. it determines whether the files get +x or not). To honor 'noexec' means Wine should honor +x.
Not correct. I've tested with vfat and ext2 filesystems, with noexec, and the files are still marked +x. As it turns out, noexec doesn't filter +x, just prevents shell/ld.so/kernel from loading the program. Wine is an indirect method of loading a program in comparison.
An interesting point, assuming that /mnt/test is mounted noexec: $ /mnt/test/test.sh bash: /mnt/test/test.sh: /bin/sh: bad interpreter: Permission denied
$ sh /mnt/test/test.sh Script runs
So maybe this is a matter of semantics: is Wine an executable handler (note binfmt-misc) or an executable interpreter? Should the Windows application, when passed as an argument to Wine, behave as if it's been called directly, or should it behave as if the executable has been passed to an interpreter (i.e., interpreter reads and processes the file as opposed to executing it directly)?
If a user is trying to execute a program on a CD that's not +x, they mounted it wrong (or the CD was made wrong). I mean, assume it was a Linux program they were trying to run on a CD instead of a Windows one. If the file doesn't have +x, it won't run. There's no reason a Windows program executed with Wine should act differently than a Linux program executed directly.
I agree with this entirely :D
On Tuesday 24 February 2009 5:51:59 pm Ben Klein wrote:
Not correct. I've tested with vfat and ext2 filesystems, with noexec, and the files are still marked +x. As it turns out, noexec doesn't filter +x, just prevents shell/ld.so/kernel from loading the program. Wine is an indirect method of loading a program in comparison.
An interesting point, assuming that /mnt/test is mounted noexec: $ /mnt/test/test.sh bash: /mnt/test/test.sh: /bin/sh: bad interpreter: Permission denied
$ sh /mnt/test/test.sh Script runs
That is interesting..
So maybe this is a matter of semantics: is Wine an executable handler (note binfmt-misc) or an executable interpreter? Should the Windows application, when passed as an argument to Wine, behave as if it's been called directly, or should it behave as if the executable has been passed to an interpreter (i.e., interpreter reads and processes the file as opposed to executing it directly)?
I would say it's as if it's called directly. After all, Wine Is Not an Emulator (and by extension, an interpreter). :) The program is run by the system, not Wine.. Wine basically just loads it into memory so the system can run it.
On 25/02/09 02:35, Chris Robinson wrote:
On Tuesday 24 February 2009 4:54:26 pm Ben Klein wrote:
"Unsolicited" files will get +x with default mount options on
vfat/fat
partitions, because ALL files on such partitions get +x this way.
You have to mount a partition to get access to its files. A
partition normally
doesn't mount itself, unless you had previously set it up to do so.
As such,
you're actively trying to get the files.. they aren't just given to you without warning.
Actually, nowadays there are most sophisticated technical solutions which mount on a single click. No warning, no options.
I would at least like to see Wine respect noexec, if possible. I understand concerns about Wine respecting +x, due mainly to CD-based installers that may or may not have +x set on the files, but I think it would also be the *correct* thing to do.
The (no)exec mount options are for specifying whether the
executable bit is
masked out or not. Filesystems like NTFS/FAT/ISO9660 do not have an
executable
bit (a shortcoming on their part), so it's always assumed to be on; the (no)exec options, in turn, control whether or not the the bit gets
filtered
out (ie. it determines whether the files get +x or not). To honor
'noexec'
means Wine should honor +x.
If a user is trying to execute a program on a CD that's not +x,
they mounted
it wrong
Yeah...by clicking on that shiny 'optical disc drive' icon.
(or the CD was made wrong).
uuhhm f.e. ISO9660 right?
I mean, assume it was a Linux program they were trying to run on a CD instead of a Windows one. If the
file doesn't
have +x, it won't run. There's no reason a Windows program executed with Wine should act differently than a Linux program executed directly.
..other than the fact that windows doesn't have the concept of an executable flag beyond the EXE extension. And wine as the linux executable that is actually being run *does* have the +x bit set... while i agree logically EXE files _should_ be flagged x aswell in practice requiring the flag ties wine's functionability to close to the randomness that is the user's choice of distrobution and its default mount options. Starting to require +x from the next release on is sure to break a lot of those systems.
On Tuesday 24 February 2009 6:01:53 pm Marcel Partap wrote:
Actually, nowadays there are most sophisticated technical solutions which mount on a single click. No warning, no options.
There are options. Whether or not said options are pre-configured sanely is another question; but that's up to the distributor. And it wouldn't be the first time distributions have made questionable decisions that have given grief to Wine.
(or the CD was made wrong).
uuhhm f.e. ISO9660 right?
I have an ISO9660 disc, and the files on it show +x...
while i agree logically EXE files _should_ be flagged x aswell in practice requiring the flag ties wine's functionability to close to the randomness that is the user's choice of distrobution and its default mount options. Starting to require +x from the next release on is sure to break a lot of those systems.
What would it break? A properly mounted CD should have +x on the exe's if you're trying to run them, and a downloaded installer can be given +x simple enough. And as mentioned before, Wine does a very good job of making sure installed programs get +x.
On Mon, Feb 23, 2009 at 5:58 PM, Zachary Goldberg zgold@bluesata.com wrote:
2009/2/23 Dan Kegel dank@kegel.com:
Ben Klein shacklein@gmail.com wrote:
http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-...
"Do not set the file association for Windows executables with Wine. This would enable running Windows executables in Wine by simply double clicking them."
I saw a patch floating by to turn this on by default recently. Maybe we should make it off by default, but easy to turn on...?
This would annoy all the people that the association targets. We can either make it easy to run all Windows apps (malware and legit) via file manager, or none at all.
Yes, exactly. The default should be off, and it should be easy to turn on.
- Dan
I disagree on this point. Is malware via Wine on Linux really a problem commonly affecting users? What happened to replicated Window's behavior bug for bug? User X might ask: double clicking an exe works in Windows why shouldn't it in Linux? Why should user X have to go through an extra step to do something on Linux than they would on Windows?
-Zach
+1
On Monday 23 February 2009 3:58:10 pm Zachary Goldberg wrote:
I disagree on this point. Is malware via Wine on Linux really a problem commonly affecting users? What happened to replicated Window's behavior bug for bug? User X might ask: double clicking an exe works in Windows why shouldn't it in Linux? Why should user X have to go through an extra step to do something on Linux than they would on Windows?
Linux isn't Windows. If anything, I think it would be a good idea to pay more attention to those non-Windows features, such as making Wine refuse to load EXEs and DLLs that aren't +x. A simple security measure, and it cleanly follows the behavior of the host system. IMO, "Windows doesn't do it that way" is not a valid excuse to not do it.
There was a blog post recently that made its way through slashdot exposing a deceptively simple attack vector for trajans on Linux. It revolved around the DE's capability of executing a program/shell script specified in a .desktop file, where neither the .desktop file nor the program being run needed +x. You could simply click on a .desktop file from an email, disguised as a "safe" iamge or text file, and the DE's associations would take care of the rest. The file didn't have to be saved somewhere and manually marked +x.. it opened and ran a program directly from the email.
Is that a good thing to be bringing to Linux/Unix? The capability for users to click on an exe in an email and have it run with no questions, beyond an "Are You Sure?" dialog that they're conditioned to click through? IMO, this is something Wine should try to avoid, even though it's perfectly acceptable in Windows.
Not sure exactly where in the thread this fits in, but here goes....
On Tue, Feb 24, 2009 at 1:58 AM, Zachary Goldberg zgold@bluesata.com wrote:
2009/2/23 Dan Kegel dank@kegel.com:
Ben Klein shacklein@gmail.com wrote:
http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-...
"Do not set the file association for Windows executables with Wine. This would enable running Windows executables in Wine by simply double clicking them."
I saw a patch floating by to turn this on by default recently. Maybe we should make it off by default, but easy to turn on...?
This would annoy all the people that the association targets. We can either make it easy to run all Windows apps (malware and legit) via file manager, or none at all.
Yes, exactly. The default should be off, and it should be easy to turn on.
- Dan
I disagree on this point. Is malware via Wine on Linux really a problem commonly affecting users? What happened to replicated Window's behavior bug for bug? User X might ask: double clicking an exe works in Windows why shouldn't it in Linux? Why should user X have to go through an extra step to do something on Linux than they would on Windows?
I posted my opinion on the matter on my blog. It basically says "Try to make like XP SP2 for downloaded files, but do it for files on drives marked as noexec as well"
http://blog.mohag.net/2009/02/sane-rules-for-determining-likely.html
Gert
2009/2/24 Dan Kegel dank@kegel.com:
Ben Klein shacklein@gmail.com wrote:
http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-...
"Do not set the file association for Windows executables with Wine. This would enable running Windows executables in Wine by simply double clicking them."
I saw a patch floating by to turn this on by default recently. Maybe we should make it off by default, but easy to turn on...?
This would annoy all the people that the association targets. We can either make it easy to run all Windows apps (malware and legit) via file manager, or none at all.
Yes, exactly. The default should be off, and it should be easy to turn on.
And if we're willing to deal with an influx of users complaining why it doesn't work like that any more, we should do it. We'd probably also have to get all the package maintainers on board though.
My packaging process doesn't do anything that explicitly associates Wine with exes, but I just tried opening an exe from Thunar and it ran ... interesting. Debian, 1.1.15
On Mon, Feb 23, 2009 at 4:00 PM, Ben Klein shacklein@gmail.com wrote:
http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-...
"Do not set the file association for Windows executables with Wine. This would enable running Windows executables in Wine by simply double clicking them."
Yes, exactly. The default should be off, and it should be easy to turn on.
And if we're willing to deal with an influx of users complaining why it doesn't work like that any more, we should do it. We'd probably also have to get all the package maintainers on board though.
Yes, this will require a modicum of consensus. We might decide to stay unsafe, or we might decide to make the bindings be in a separate package, so it's easier for admins to flip the switch.
My packaging process doesn't do anything that explicitly associates Wine with exes, but I just tried opening an exe from Thunar and it ran ... interesting. Debian, 1.1.15
Yep. - Dan
On Mon, Feb 23, 2009 at 4:06 PM, Dan Kegel dank@kegel.com wrote:
"Do not set the file association for Windows executables with Wine. This would enable running Windows executables in Wine by simply double clicking them."
Yes, this will require a modicum of consensus. We might decide to stay unsafe, or we might decide to make the bindings be in a separate package, so it's easier for admins to flip the switch.
As someone else mentioned, it's probably safe for the file manager's doubleclick handler to execute programs that are marked executable. The option would be whether to let it execute ones not marked executable. - Dan
Dan Kegel wrote:
On Mon, Feb 23, 2009 at 4:00 PM, Ben Klein shacklein@gmail.com wrote:
http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-...
"Do not set the file association for Windows executables with Wine. This would enable running Windows executables in Wine by simply double clicking them."
Yes, exactly. The default should be off, and it should be easy to turn on.
And if we're willing to deal with an influx of users complaining why it doesn't work like that any more, we should do it. We'd probably also have to get all the package maintainers on board though.
Yes, this will require a modicum of consensus. We might decide to stay unsafe, or we might decide to make the bindings be in a separate package, so it's easier for admins to flip the switch.
My packaging process doesn't do anything that explicitly associates Wine with exes, but I just tried opening an exe from Thunar and it ran ... interesting. Debian, 1.1.15
Yep.
- Dan
When I brought this up at the Ubuntu Developer Summit a while back, the security conscious there wanted to check an executable for the execute bit before launching it with Wine. Then, the user would be prompted if they wanted to run it, and if yes the execute bit would be set and the program launched.
This check would be skipped if you clicked a link on the start menu (since you obviously meant to launch a program then).
That said, there's no point becoming "safe" until the desktop also disables single click running of .desktop files that don't have the execute bit set. It's trivial to write a piece of Linux malware that does whatever you want by making it a .desktop file - you can even make it so it displays as whatever name you like (and not foo.desktop).
Thanks, Scott Ritchie
On Tue, Feb 24, 2009 at 6:07 PM, Scott Ritchie scott@open-vote.org wrote:
When I brought this up at the Ubuntu Developer Summit a while back, the security conscious there wanted to check an executable for the execute bit before launching it with Wine. Then, the user would be prompted if they wanted to run it, and if yes the execute bit would be set and the program launched.
This check would be skipped if you clicked a link on the start menu (since you obviously meant to launch a program then).
Sounds good. A helper app could do this for us, I think.
That said, there's no point becoming "safe" until the desktop also disables single click running of .desktop files that don't have the execute bit set. It's trivial to write a piece of Linux malware that does whatever you want by making it a .desktop file - you can even make it so it displays as whatever name you like (and not foo.desktop).
Right. Both changes are needed, the .desktop one more urgently. - Dan
Dan Kegel wrote:
On Tue, Feb 24, 2009 at 6:07 PM, Scott Ritchie scott@open-vote.org wrote:
When I brought this up at the Ubuntu Developer Summit a while back, the security conscious there wanted to check an executable for the execute bit before launching it with Wine. Then, the user would be prompted if they wanted to run it, and if yes the execute bit would be set and the program launched.
This check would be skipped if you clicked a link on the start menu (since you obviously meant to launch a program then).
Sounds good. A helper app could do this for us, I think.
That said, there's no point becoming "safe" until the desktop also disables single click running of .desktop files that don't have the execute bit set. It's trivial to write a piece of Linux malware that does whatever you want by making it a .desktop file - you can even make it so it displays as whatever name you like (and not foo.desktop).
Right. Both changes are needed, the .desktop one more urgently.
That's already solved in nautilus;
http://svn.gnome.org/viewvc/nautilus?view=revision&revision=15003
Johan
On Wed, Feb 25, 2009 at 7:56 AM, Johan Dahlin johan@gnome.org wrote:
Dan Kegel wrote:
On Tue, Feb 24, 2009 at 6:07 PM, Scott Ritchie scott@open-vote.org
wrote:
When I brought this up at the Ubuntu Developer Summit a while back, the security conscious there wanted to check an executable for the execute bit before launching it with Wine. Then, the user would be prompted if they wanted to run it, and if yes the execute bit would be set and the program launched.
This check would be skipped if you clicked a link on the start menu (since you obviously meant to launch a program then).
Sounds good. A helper app could do this for us, I think.
That said, there's no point becoming "safe" until the desktop also disables single click running of .desktop files that don't have the execute bit set. It's trivial to write a piece of Linux malware that does whatever you want by making it a .desktop file - you can even make it so it displays as whatever name you like (and not foo.desktop).
Right. Both changes are needed, the .desktop one more urgently.
That's already solved in nautilus;
http://svn.gnome.org/viewvc/nautilus?view=revision&revision=15003
Johan
Now that Nautilus has the desktop file requiring execute bit, I have a question for all of you to consider. Do JAR files require the +x bit to load them, or are they treated like associated files and run through the interpreter? Really, Windows apps on Linux is basically the same situation as Java applications run through the bytecode interpreter. Most distros do not treat Java JAR files are executables, but rather as an associated file to the JVM. AFAIK, the main difference between the Wine and Java methods is that Wine doesn't sandbox its loading environment, while Java does. If Wine used a W32VM of some kind, then it would make more sense _not_ to require the execute bit. However, it does not use one, so it would make sense to have the execute bit.
Also, NTFS DOES have a concept of execute bits, but Windows itself does not use them. An implementation of this is the "trusted" app scheme in the properties in Windows Vista and above (I don't remember if XPSP2 had it also). Although this scheme is mostly broken, it was intended to stop the execution of apps just downloaded from the internet from a non-trusted source.
On Wednesday 25 February 2009 8:38:15 am King InuYasha wrote:
Now that Nautilus has the desktop file requiring execute bit, I have a question for all of you to consider. Do JAR files require the +x bit to load them, or are they treated like associated files and run through the interpreter? Really, Windows apps on Linux is basically the same situation as Java applications run through the bytecode interpreter.
Not really. When Java byte code is run through an interpreter, the program is implicitly bound by what the JRE allows. If the JRE does not allow you to access feature X, the program can't access feature X in any way (barring fixable bugs, of course). The JRE is in control of the program.
A program loaded with Wine, by contrast, can do anything a normal program can. All Wine does is set up an initial environment Windows apps expect, loads the program into memory, then sets it off to run on its own. Wine cannot disallow a program from accessing feature X if it wants to. The program is in control of Wine.
On Wed, Feb 25, 2009 at 10:38 AM, King InuYasha ngompa13@gmail.com wrote:
AFAIK, the main difference between the Wine and Java methods is that Wine doesn't sandbox its loading environment, while Java does.
Java doesn't create a sandbox when you run a normal application.
Which makes it a wonderful example.
This discussion has been assuming that .exe files are somehow special because they are programs (and thus can do anything your user can do), but they shouldn't be executed directly (before anyone mentions binfmt-support, that's broken and unfixable for this case). I don't think exe is likely to be the only file type like that. What we really should do is make sure the file manager knows about these types so it can apply a consistent policy.
This information would also be useful to firefox and any other program that handles possibly-untrusted files of arbitrary type.
Vincent Povirk
On Wednesday 25 February 2009 9:22:29 am Vincent Povirk wrote:
This discussion has been assuming that .exe files are somehow special because they are programs
Actually, I'm saying just the opposite. They are *not* special because they are programs, and should honor the executable bit just like any other program should.
What we really should do is make sure the file manager knows about these types so it can apply a consistent policy.
You mean that dolphin, nautilus, konqueror, firefox, kmail, and anything that can "open" a file should all be made aware of what the different types of files can do? Is it really their responsibility?
IMO, it would be better to just hand off a file to its associated program, whether that program is wine, kwrite, firefox, or what-have-you.. the handler should know the type of file better than a file manager, and the handler can be made to honor the proper permissions much easier and quicker than trying to keep all file managers up-to-date.
As an example, suppose Dolphin is made to be aware that exe files are programs, and thus restricts opening it with Wine if +x isn't set. A new app comes along that does not know anything special about exe files and/or passes it off to Wine as the associated program anyway. It becomes popular, and the less-technically-inclined people start using it. That puts us right back at square one.
2009/2/26 King InuYasha ngompa13@gmail.com:
Now that Nautilus has the desktop file requiring execute bit, I have a question for all of you to consider. Do JAR files require the +x bit to load them, or are they treated like associated files and run through the interpreter? Really, Windows apps on Linux is basically the same situation as Java applications run through the bytecode interpreter.
You just answered your own question. Java is interpreted and has to be passed through a compatible byte-code interpreter. Wine does not interpret PE files in this fashion, and cannot because it is not and does not have a CPU emulator. So a JAR file should run if passed as an argument to the interpreter, just like what happens with the scripting languages that open the file for reading instead of trying to fork and execute.
Also, NTFS DOES have a concept of execute bits, but Windows itself does not use them. An implementation of this is the "trusted" app scheme in the properties in Windows Vista and above (I don't remember if XPSP2 had it also). Although this scheme is mostly broken, it was intended to stop the execution of apps just downloaded from the internet from a non-trusted source.
NTFS has the concept of metadata. Windows does not use it as an equivalent for +x bit though. And even if it did, it wouldn't be a big help for Wine, because Wine doesn't like NTFS :)
2009/2/26 Scott Ritchie scott@open-vote.org:
It's hardly annoying as it takes all of two seconds (or less). It's part of normal system operation that the user will already have to deal with outside of Wine. And at least they'll know that it's something that is going to be executing, instead of simply opened/read. Trading safety for user convenience like that is a bad habit to pick up.
It takes about 2 seconds once you've learned how to do this, but this is hardly an easily discoverable task.
One word for you: EDUCATION. Newbies should be taught how things work. We shouldn't base all our usability decisions based on what they expect. They expect it to "just work". The only case we're talking about here where it won't "just work" is when they download an app to install; in this case they have to +x it explicitly. Just like if it was a regular ELF executable.
Regardless, when a user says "open the program" twice in a row - by clicking on it and then clicking "run this program" on the associated dialog box, I think it best we got out of their way rather than assume they actually meant "no, don't run it until I make 4 more clicks on a different tab in the preferences dialog."
Wow 4 more clicks? That might give me RSI! Why don't we get out of their way entirely and automatically run wineboot when they log on to an X session, so they get Steam and all their trojans running without warning?
People seem to forget that security comes at the cost of convenience. In my opinion, requiring +x is not just about security (for downloaded applications in particular) but about correctness. Wine is not an interpreter, it's a binary loader. It should act like a binary loader and respect +x. If possible, it should respect noexec mount option too.
Does Wine do this in all cases (mark installed executables as +x)?
I believe so. As it's been mentioned, Wine goes to great lengths to make sure EXEs are marked +x, but it doesn't do anything else with it. I expect that this is mostly to keep binfmt-misc happy.
What this thread needs now is a final decision from AJ. :)
On Wed, Feb 25, 2009 at 6:50 PM, Ben Klein shacklein@gmail.com wrote:
2009/2/26 King InuYasha ngompa13@gmail.com:
Now that Nautilus has the desktop file requiring execute bit, I have a question for all of you to consider. Do JAR files require the +x bit to
load
them, or are they treated like associated files and run through the interpreter? Really, Windows apps on Linux is basically the same
situation
as Java applications run through the bytecode interpreter.
You just answered your own question. Java is interpreted and has to be passed through a compatible byte-code interpreter. Wine does not interpret PE files in this fashion, and cannot because it is not and does not have a CPU emulator. So a JAR file should run if passed as an argument to the interpreter, just like what happens with the scripting languages that open the file for reading instead of trying to fork and execute.
But, doesn't Wine translate Win32 calls into its equivalent calls for Linux? GDI to X11, D3D to OpenGL, etc.? That sounds like an interpreter to me. It may not necessarily a bytecode interpreter, but it still interprets the Win32 API and translates it to the appropriate UNIX APIs. Isn't this what makes Wine not an emulator?
2009/2/26 King InuYasha ngompa13@gmail.com:
On Wed, Feb 25, 2009 at 6:50 PM, Ben Klein shacklein@gmail.com wrote:
2009/2/26 King InuYasha ngompa13@gmail.com:
Now that Nautilus has the desktop file requiring execute bit, I have a question for all of you to consider. Do JAR files require the +x bit to load them, or are they treated like associated files and run through the interpreter? Really, Windows apps on Linux is basically the same situation as Java applications run through the bytecode interpreter.
You just answered your own question. Java is interpreted and has to be passed through a compatible byte-code interpreter. Wine does not interpret PE files in this fashion, and cannot because it is not and does not have a CPU emulator. So a JAR file should run if passed as an argument to the interpreter, just like what happens with the scripting languages that open the file for reading instead of trying to fork and execute.
But, doesn't Wine translate Win32 calls into its equivalent calls for Linux? GDI to X11, D3D to OpenGL, etc.? That sounds like an interpreter to me. It may not necessarily a bytecode interpreter, but it still interprets the Win32 API and translates it to the appropriate UNIX APIs. Isn't this what makes Wine not an emulator?
It's a compatibility layer. It doesn't actually interpret individual instructions. As described earlier, Wine sets up an environment suitable for the Windows apps to run in (which is primarily *implementations* of win32 calls that "translate" in one way or another into *nix/X11 calls) and then just lets it do its thing. Unlike in Java, scripting languages etc, Wine does not read in the application one instruction at a time and do a mapping/translation into executable functionality. The assembly components (such as mathematical operations) run as if it was a native application.
On Wed, Feb 25, 2009 at 7:37 PM, Ben Klein shacklein@gmail.com wrote:
2009/2/26 King InuYasha ngompa13@gmail.com:
On Wed, Feb 25, 2009 at 6:50 PM, Ben Klein shacklein@gmail.com wrote:
2009/2/26 King InuYasha ngompa13@gmail.com:
Now that Nautilus has the desktop file requiring execute bit, I have a question for all of you to consider. Do JAR files require the +x bit
to
load them, or are they treated like associated files and run through the interpreter? Really, Windows apps on Linux is basically the same situation as Java applications run through the bytecode interpreter.
You just answered your own question. Java is interpreted and has to be passed through a compatible byte-code interpreter. Wine does not interpret PE files in this fashion, and cannot because it is not and does not have a CPU emulator. So a JAR file should run if passed as an argument to the interpreter, just like what happens with the scripting languages that open the file for reading instead of trying to fork and execute.
But, doesn't Wine translate Win32 calls into its equivalent calls for
Linux?
GDI to X11, D3D to OpenGL, etc.? That sounds like an interpreter to me. It may not necessarily a bytecode interpreter, but it still interprets the Win32 API and translates it to
the
appropriate UNIX APIs. Isn't this what makes Wine not an emulator?
It's a compatibility layer. It doesn't actually interpret individual instructions. As described earlier, Wine sets up an environment suitable for the Windows apps to run in (which is primarily *implementations* of win32 calls that "translate" in one way or another into *nix/X11 calls) and then just lets it do its thing. Unlike in Java, scripting languages etc, Wine does not read in the application one instruction at a time and do a mapping/translation into executable functionality. The assembly components (such as mathematical operations) run as if it was a native application.
So, in theory, Wine could simply run itself on top of Linux (basically a ReactOS desktop on top of Linux instead of the NT kernel) and work just like Windows because it operates in a native app style? Granted, that probably would require quite a bit of tweaking to get it done, and the devs probably wouldn't want to do it, but because of its design, that would be possible?
2009/2/26 King InuYasha ngompa13@gmail.com:
So, in theory, Wine could simply run itself on top of Linux (basically a ReactOS desktop on top of Linux instead of the NT kernel) and work just like Windows because it operates in a native app style? Granted, that probably would require quite a bit of tweaking to get it done, and the devs probably wouldn't want to do it, but because of its design, that would be possible?
Yes, it's possible to run a win32 userland on Linux via Wine. It's been tried before, but none of the projects have survived. It's also not possible to make EVERY application that works in Windows work in Wine. This might be reduced if Gallium3D or GEM allows DirectX calls to the graphics cards, but there would still be apps that do checksums of system DLLs that would fail on Wine ...
Anyway, this is diverging from the topic :)
On Thu, Feb 26, 2009 at 2:37 AM, Ben Klein shacklein@gmail.com wrote:
It's a compatibility layer. It doesn't actually interpret individual instructions. As described earlier, Wine sets up an environment suitable for the Windows apps to run in (which is primarily *implementations* of win32 calls that "translate" in one way or another into *nix/X11 calls) and then just lets it do its thing. Unlike in Java, scripting languages etc, Wine does not read in the application one instruction at a time and do a mapping/translation into executable functionality. The assembly components (such as mathematical operations) run as if it was a native application.
Indeed. You could say that Linux userland is a "Linux compatibility layer" just like Wine is one for Windows. It's mostly the same level of abstraction.
Except of course for D3D. There are no drivers that expose the GPU. Only OpenGL. But that may change with Gallium3D. I don't know what problem that would solve though.
Remco
On Thu, Feb 26, 2009 at 2:50 AM, Ben Klein shacklein@gmail.com wrote:
2009/2/26 King InuYasha ngompa13@gmail.com:
Also, NTFS DOES have a concept of execute bits, but Windows itself does not use them. An implementation of this is the "trusted" app scheme in the properties in Windows Vista and above (I don't remember if XPSP2 had it also). Although this scheme is mostly broken, it was intended to stop the execution of apps just downloaded from the internet from a non-trusted source.
NTFS has the concept of metadata. Windows does not use it as an equivalent for +x bit though. And even if it did, it wouldn't be a big help for Wine, because Wine doesn't like NTFS :)
http://msdn.microsoft.com/en-us/library/bb776297(VS.85).aspx
(And I mentioned it in my blog post mentioned earlier)
Gert
On Tuesday 24 February 2009 6:07:08 pm Scott Ritchie wrote:
When I brought this up at the Ubuntu Developer Summit a while back, the security conscious there wanted to check an executable for the execute bit before launching it with Wine. Then, the user would be prompted if they wanted to run it, and if yes the execute bit would be set and the program launched.
Seems a bit too easy to me for this to be ineffective. It's been repeated often around here how people, especially Windows users, are conditioned to click "Yes" and not actually see or comprehend what they're clicking yes too ("I thought it was going to open it in notepad, not run it!"). IMHO, it would be better if they had to take the initiative to mark it +x, then run it again. That would prevent these kinds of surprises.
This check would be skipped if you clicked a link on the start menu (since you obviously meant to launch a program then).
Not necessarily. Along with the .desktop trojan, the blog I read also showed how to override system menu entries (by placing a replacement in the local folder which will override the system one). So the link you clicked on may not be what you intended..
Chris Robinson wrote:
On Tuesday 24 February 2009 6:07:08 pm Scott Ritchie wrote:
When I brought this up at the Ubuntu Developer Summit a while back, the security conscious there wanted to check an executable for the execute bit before launching it with Wine. Then, the user would be prompted if they wanted to run it, and if yes the execute bit would be set and the program launched.
Seems a bit too easy to me for this to be ineffective. It's been repeated often around here how people, especially Windows users, are conditioned to click "Yes" and not actually see or comprehend what they're clicking yes too ("I thought it was going to open it in notepad, not run it!"). IMHO, it would be better if they had to take the initiative to mark it +x, then run it again. That would prevent these kinds of surprises.
It would also make it completely unusable. Remember, all downloaded executables (even intentionally downloaded ones) will be -x by default. Do you really expect users to go right click->properties->permissions->allow execution? Or will they just conclude that it doesn't work.
Worse, you could actively irritate them - suppose they do double click and you DONT offer the ability to open it, but instead instruct them to go through that annoying procedure.
This check would be skipped if you clicked a link on the start menu (since you obviously meant to launch a program then).
Not necessarily. Along with the .desktop trojan, the blog I read also showed how to override system menu entries (by placing a replacement in the local folder which will override the system one). So the link you clicked on may not be what you intended..
But in order to do that a malicious script has to already be running! Such a system is already owned.
Thanks, Scott Ritchie
2009/2/25 Scott Ritchie scott@open-vote.org:
Chris Robinson wrote:
On Tuesday 24 February 2009 6:07:08 pm Scott Ritchie wrote:
When I brought this up at the Ubuntu Developer Summit a while back, the security conscious there wanted to check an executable for the execute bit before launching it with Wine. Then, the user would be prompted if they wanted to run it, and if yes the execute bit would be set and the program launched.
Seems a bit too easy to me for this to be ineffective. It's been repeated often around here how people, especially Windows users, are conditioned to click "Yes" and not actually see or comprehend what they're clicking yes too ("I thought it was going to open it in notepad, not run it!"). IMHO, it would be better if they had to take the initiative to mark it +x, then run it again. That would prevent these kinds of surprises.
It would also make it completely unusable. Remember, all downloaded executables (even intentionally downloaded ones) will be -x by default. Do you really expect users to go right click->properties->permissions->allow execution? Or will they just conclude that it doesn't work.
Worse, you could actively irritate them - suppose they do double click and you DONT offer the ability to open it, but instead instruct them to go through that annoying procedure.
And what happens if they intentionally download a Linux-native executable or script? It won't run unless it's marked +x or passed as an argument to the appropriate interpreter. Wine/Windows apps shouldn't be different.
It's admirable to think of new users and say "how much will they get?", but you're holding them back if you don't educate them with things like this. If it's the *correct* way to do it, which I believe it is, it's *incorrect* to assume that new users are incapable of learning how to +x their apps when they're downloaded.
This check would be skipped if you clicked a link on the start menu (since you obviously meant to launch a program then).
Not necessarily. Along with the .desktop trojan, the blog I read also showed how to override system menu entries (by placing a replacement in the local folder which will override the system one). So the link you clicked on may not be what you intended..
But in order to do that a malicious script has to already be running! Such a system is already owned.
What he's talking about here, if I understand correctly, is a .desktop file that can be clicked on in a web browser, and executed by the system without warning. It's an entry-point for malware.
On Tuesday 24 February 2009 8:57:23 pm Scott Ritchie wrote:
It would also make it completely unusable. Remember, all downloaded executables (even intentionally downloaded ones) will be -x by default. Do you really expect users to go right click->properties->permissions->allow execution? Or will they just conclude that it doesn't work.
I would expect them to mark it executable. That's how most Unix systems work. A Linux-native executable/script would need to be set as executable by the user all the same.
Worse, you could actively irritate them - suppose they do double click and you DONT offer the ability to open it, but instead instruct them to go through that annoying procedure.
It's hardly annoying as it takes all of two seconds (or less). It's part of normal system operation that the user will already have to deal with outside of Wine. And at least they'll know that it's something that is going to be executing, instead of simply opened/read. Trading safety for user convenience like that is a bad habit to pick up.
Not necessarily. Along with the .desktop trojan, the blog I read also showed how to override system menu entries (by placing a replacement in the local folder which will override the system one). So the link you clicked on may not be what you intended..
But in order to do that a malicious script has to already be running! Such a system is already owned.
True enough, I suppose. It just seems unnecessary to me to special-case it since a program installed via Wine (that would have created such a menu entry) is already marked as +x. What kind of scenario would there be for a user to have a menu entry and the program its pointing to to unknowingly be -x?
Chris Robinson wrote:
On Tuesday 24 February 2009 8:57:23 pm Scott Ritchie wrote:
Worse, you could actively irritate them - suppose they do double click and you DONT offer the ability to open it, but instead instruct them to go through that annoying procedure.
It's hardly annoying as it takes all of two seconds (or less). It's part of normal system operation that the user will already have to deal with outside of Wine. And at least they'll know that it's something that is going to be executing, instead of simply opened/read. Trading safety for user convenience like that is a bad habit to pick up.
It takes about 2 seconds once you've learned how to do this, but this is hardly an easily discoverable task.
Regardless, when a user says "open the program" twice in a row - by clicking on it and then clicking "run this program" on the associated dialog box, I think it best we got out of their way rather than assume they actually meant "no, don't run it until I make 4 more clicks on a different tab in the preferences dialog."
Not necessarily. Along with the .desktop trojan, the blog I read also showed how to override system menu entries (by placing a replacement in the local folder which will override the system one). So the link you clicked on may not be what you intended..
But in order to do that a malicious script has to already be running! Such a system is already owned.
True enough, I suppose. It just seems unnecessary to me to special-case it since a program installed via Wine (that would have created such a menu entry) is already marked as +x. What kind of scenario would there be for a user to have a menu entry and the program its pointing to to unknowingly be -x?
Does Wine do this in all cases (mark installed executables as +x)?
Thanks, Scott Ritchie
On Tue, Feb 24, 2009 at 12:49 AM, Dan Kegel dank@kegel.com wrote:
http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-... is an interesting report; all the malware he tried ran to at least some extent on wine.
One interesting bit of advice he gives at the end is
"Do not set the file association for Windows executables with Wine. This would enable running Windows executables in Wine by simply double clicking them."
I saw a patch floating by to turn this on by default recently. Maybe we should make it off by default, but easy to turn on...?
That patch, which I wrote, works a differently than you describe.
It generates an association from a file extension, to open with the handler for its ProgID currently in the registry.
So it allows .txt to open with Notepad and .dev to open with Dev-C++. It does not make Wine open a new .exe by default - at least, that was not the intention.
Windows executables already run in Wine when you double click on them - that's tools/wine.desktop doing it's job.
Damjan
2009/2/24 Damjan Jovanovic damjan.jov@gmail.com:
It generates an association from a file extension, to open with the handler for its ProgID currently in the registry.
So it allows .txt to open with Notepad and .dev to open with Dev-C++. It does not make Wine open a new .exe by default - at least, that was not the intention.
This reminds me of something. On some (all? at least, all with registry?) versions of Windows, when the user double-clicks a .exe, .com, .bat etc, Windows looks up the handler for that filetype in the registry. Some malware (and potentially some virus scanners too) replace the .exe, .dll, .com etc handlers with a rundll32 call that pre-processes the executable.
Now, I'm pretty sure Wine doesn't do this. Someone correct me if I'm wrong. In terms of bug-for-bug compatibility, it should, but I think in this case it would be safe to diverge from bug-for-bug :)
On Tue, Feb 24, 2009 at 9:59 AM, Ben Klein shacklein@gmail.com wrote:
2009/2/24 Damjan Jovanovic damjan.jov@gmail.com:
It generates an association from a file extension, to open with the handler for its ProgID currently in the registry.
So it allows .txt to open with Notepad and .dev to open with Dev-C++. It does not make Wine open a new .exe by default - at least, that was not the intention.
This reminds me of something. On some (all? at least, all with registry?) versions of Windows, when the user double-clicks a .exe, .com, .bat etc, Windows looks up the handler for that filetype in the registry. Some malware (and potentially some virus scanners too) replace the .exe, .dll, .com etc handlers with a rundll32 call that pre-processes the executable.
Now, I'm pretty sure Wine doesn't do this. Someone correct me if I'm wrong. In terms of bug-for-bug compatibility, it should, but I think in this case it would be safe to diverge from bug-for-bug :)
I'll blacklist .exe and .com in the file type associations patch I'm working on. They open through wine.desktop anyway and should be fixed there. The .dll shouldn't open at all - it doesn't on Windows.
Damjan
-
Austin English -
Ben Klein -
Chris Robinson -
Damjan Jovanovic -
Dan Kegel -
Gert van den Berg -
Jerome Leclanche -
Johan Dahlin -
King InuYasha -
Marcel Partap -
Paul Chitescu -
Remco -
Scott Ritchie -
Vincent Povirk -
Zachary Goldberg