February 2009 - Wine-Devel - list.winehq.org

Re: Malware on Wine review

by Marcel Partap

On 25/02/09 01:54, Ben Klein wrote: > 2009/2/25 Chris Robinson<chris.kcat(a)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. -- "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

Feb. 25, 2009

Re: Malware on Wine review

by Ben Klein

2009/2/25 Chris Robinson <chris.kcat(a)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.

Feb. 25, 2009

Re: Malware on Wine review

by Chris Robinson

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.

Feb. 25, 2009

Re: Malware on Wine review

by Paul Chitescu

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.

Feb. 24, 2009

Re: [2/2] WineD3D: Create a common sampling function in GLSL

by Paul Vriens

Stefan Dösinger wrote: > > > You forgot the patch ;) -- Cheers, Paul.

Feb. 24, 2009

Re: Malware on Wine review

by Chris Robinson

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.

Feb. 24, 2009

re: makedep: let umask decide mode for Makefiles

by Dan Kegel

Paul Bryan Roberts write: > The code as it stands creates makefiles with a mode of 600. This may be > benign on most (e.g. personal workstation) installations but not all. > >An example is where the wine git repository is located on an NFS >volume. Here security settings may mean that root:root is treated as >nobody:nogroup. Installation from the repository is not possible as >root (whether via su or sudo) cannot even read the makefiles Where I work, NFS is set up so root cannot access any NFS volumes, period, because you really can't trust remote systems that much with NFS.

Feb. 24, 2009

Re: [6/6] shell32: implement Get/SetIDList on ShellItem objects

by Alexandre Julliard

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > + ILFree(This->pidl); > + This->pidl = ILClone(pidl); > + if (This->pidl) > + return S_OK; > + else > + return E_OUTOFMEMORY; You should check for success before you free the previous pidl. -- Alexandre Julliard julliard(a)winehq.org

Feb. 24, 2009

Wine's malware compatibility: good

by David Gerard

http://www.trustedsource.org/blog/186/Running-Windows-Malware-in-Linux With apps like ZeroWine, we can I think expect to see Windows binaries that try int 0x80 calls just because they might be useful and a Linux box will make a much more robust host. - d.

Feb. 24, 2009

Re: Malware on Wine review

by Damjan Jovanovic

On Tue, Feb 24, 2009 at 9:59 AM, Ben Klein <shacklein(a)gmail.com> wrote: > 2009/2/24 Damjan Jovanovic <damjan.jov(a)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

Feb. 24, 2009