Bug#733556: [pkg-wine-party] Bug#733556: wine: binfmt-support got lost
control: severity -1 wishlist On Sun, Dec 29, 2013 at 5:03 PM, Tobias Schlemmer wrote: the binfmt support for wine has been dropped (at least /usr/share/binfmts/wine and winelauncher). I consider this a wishlist request. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: [pkg-wine-party] Bug#733556: wine: binfmt-support got lost
Processing control commands: severity -1 wishlist Bug #733556 [wine] wine: binfmt-support got lost Severity set to 'wishlist' from 'grave' -- 733556: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733556 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733556: binfmt detectors for Windows executables
On Sun, 9 Mar 2014 10:40:42 +, Colin Watson cjwat...@debian.org wrote: On Sat, Mar 08, 2014 at 01:44:15PM +0100, Stephen Kitt wrote: I was working on restoring binfmt support to wine (http://bugs.debian.org/733556) and I came across the detectors spec in binfmt-support. The latter mentions detection code to handle Windows binaries which Alp Toker has - is that still the case, Alp? I quote: As far as wine is concerned, the modification should be as follows: add /usr/lib/wine/binfmt-detector-wine or similar with the Win32 format detection code (Alp has the details of this, it's a few dozen lines of C), and add 'detector /usr/lib/wine/binfmt-detector-wine' to /usr/share/binfmts/wine. This was for Mono. I think the descendant of this has wound up in debian/detector/binfmt-detector-cli.c in the Debian mono source package; looking at that it should be fairly straightforward to invert (or similar) the relevant bit of logic for Win32. OK, thanks! Regards, Stephen signature.asc Description: PGP signature
Bug#733556: binfmt detectors for Windows executables
On Sat, Mar 08, 2014 at 01:44:15PM +0100, Stephen Kitt wrote: I was working on restoring binfmt support to wine (http://bugs.debian.org/733556) and I came across the detectors spec in binfmt-support. The latter mentions detection code to handle Windows binaries which Alp Toker has - is that still the case, Alp? I quote: As far as wine is concerned, the modification should be as follows: add /usr/lib/wine/binfmt-detector-wine or similar with the Win32 format detection code (Alp has the details of this, it's a few dozen lines of C), and add 'detector /usr/lib/wine/binfmt-detector-wine' to /usr/share/binfmts/wine. This was for Mono. I think the descendant of this has wound up in debian/detector/binfmt-detector-cli.c in the Debian mono source package; looking at that it should be fairly straightforward to invert (or similar) the relevant bit of logic for Win32. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733556: binfmt detectors for Windows executables
Hi, I was working on restoring binfmt support to wine (http://bugs.debian.org/733556) and I came across the detectors spec in binfmt-support. The latter mentions detection code to handle Windows binaries which Alp Toker has - is that still the case, Alp? I quote: As far as wine is concerned, the modification should be as follows: add /usr/lib/wine/binfmt-detector-wine or similar with the Win32 format detection code (Alp has the details of this, it's a few dozen lines of C), and add 'detector /usr/lib/wine/binfmt-detector-wine' to /usr/share/binfmts/wine. Thanks in advance, Stephen signature.asc Description: PGP signature
Bug#733556: Ok I think someone has this issue backwards.
On Tue, Mar 4, 2014 at 10:51 PM, Jakub Wilk jw...@debian.org wrote: * Peter Dolding oia...@gmail.com, 2014-03-04, 13:11: wine should not be run as root. There is no wrapper on binfmt_misc to make it fail in case of a .exe on root. Why should such a protection be implemented in the wrapped rather than in wine itself? In diagnostics with wine you may intentionally run as root taking the understanding of the security.It should not be a direct up run, Reason why wine should not run as root. Wine can run Windows viruses very effectively. Huh. /bin/sh can run Linux malware very effectively. Does it mean that we shouldn't let users run #!/bin/sh scripts as root?! A virus in wine cannot tell the difference at times between a windows PE file and your vmlinuz and other ELF files and when it write PE code into your kernel image and applications files of your OS for some reason does not boot any more. Basically a mucked up virus in wine will destroy all ELF files on a Linux system if it can. Only can do this if you run as root. This is not the malware doing what is was designed todo. Its how the malware malfunctions in wine. /bin/sh script as root can do damage but it will be doing what it was indented todo. A /bin/sh malware unless the author is particularly evil is not going to destroy your system. Most malware writers want to keep you system running issue here the virus/malware program running in wine may not be doing what the writer indented any more. The Wine FAQ makes it very clear. http://wiki.winehq.org/FAQ#head-96bebfa287b4288974de0df23351f278b0d41014 This is the problem implementation is disobeying upstream recommendations. Number 2 WINEPREFIX settings. Direct running by binfmt_misc cannot tell that X application in fact owns to alternative WINEPREFIX. Wine does not use extended Xattr to declare WINEPREFIX ownership on .exe files. No idea what you're talking about here. Wine when you install applications can be installed into unique paths. http://wiki.winehq.org/FAQ#wineprefix Running an application in the WINEPREFIX its was not installed in can destroy that WINEPREFIX from operating. This is a bug that comes out of ./foo.exe working.Mono and Java .exe files don't have this issue. Yes there is something special about wine that makes being in binfmt_misc a problem. Users can have a mix of both wine and mono .exe from the outside they can look identical. System does need to treat them differently. Really I would like to hear the real-world examples that require this feature. Like Mathieu, I've been using this feature to ease cross-compiling. Basically the broken state is a good time to patch up a security issue. Please explain why do you think that this is a security issue: ./foo.exe but this is not: wine foo.exe That it is an intentional action you have to type wine with binfmt_misc off so you have a chance to know you about to run a program that could fully malfunction. There is something you have missed about binfmt_misc and Wine itself does not check that an executable ends in .exe. So it is ./foo vs wine ./foo So grep.exe with exe missing will run if you have binfmt_misc enabled now something like this on the look up PATH can cause major hazard. Windows programs from wine don't always output clean UTF8 either why the UTF16 to UTF8 translation. Yes there are tones of ways in a simple typo declaring PATH that wine wine binfmt_misc on can turn into a disaster. Other thing what about ./foo.exe tells you that is wine it could be mono could be dos. wine foo.exe tells user they are running wine. Its important that the end user is aware when they are running wine. Due to wine issues having teeth. Now mono and dos programs are not going to cause a failure being run incorrectly where wine running windows exes wrong can break the users default ~/.wine or whatever they exported WINEPREFIX as. So ./foo.exe something now MS Office WINEPREFIX is dead because that was a the default and foo.exe was a not properly installed windows application that a person thought was a mono application all because binfmt_misc was enabled. Yes us debugging that in wine support channels is hell. Wine is running an alien system inside Linux with its own unique issues working around the alien issues. So from what you have said there is a case you use it for cross complier building. Not everyone does. So there is a case for the binfmt_misc for wine to be in its own package. I would not argue about it being in it own package. Developers not making windows programs don't need and general desktop users don't need it. Basically its been a bad default its harms users who don't need it by making particular set of mistakes possible. Peter Dolding -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733556: Ok I think someone has this issue backwards.
On Tue, Mar 4, 2014 at 4:11 AM, Peter Dolding oia...@gmail.com wrote:
Basically as far as the main wine project knows no end user has an use
for binfmt_misc loading .exe files. So to them its one of those
bright spark ideas by package makers without any consideration to
security.
I do.
From my cmake build system setup, a test is simply a command line
application returning EXIT_SUCCESS / EXIT_FAILED.
$ cmake --help-command add_test
[...]
add_test(NAME testname COMMAND Exename arg1 arg2 ... )
[...]
Therefore I'd like to be able to use binfmt_misc just like any other
qemu-* (+binfmt_misc) simulated environment. Steps (within the *same*
machine, thanks to recent multiarch wine32/64 setup):
$ cat bla.c
int main() { return 0; }
$ i586-mingw32msvc-gcc -o bla.exe bla.c
$ export WINEPREFIX=~/wine32
$ ./bla.exe echo ok
ok
$ x86_64-w64-mingw32-gcc -o bla2.exe bla.c
$ export WINEPREFIX=~/wine64
$./bla2.exe echo ok
ok
This works very well for me and I like it this way, I can run cross
compilation + test executions targeting wine 32bits *and* 64bits .
This machine is a compilation machine, I have no issues with security
concerns.
2cts
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733556: Ok I think someone has this issue backwards.
* Peter Dolding oia...@gmail.com, 2014-03-04, 13:11: wine should not be run as root. There is no wrapper on binfmt_misc to make it fail in case of a .exe on root. Why should such a protection be implemented in the wrapped rather than in wine itself? Reason why wine should not run as root. Wine can run Windows viruses very effectively. Huh. /bin/sh can run Linux malware very effectively. Does it mean that we shouldn't let users run #!/bin/sh scripts as root?! Number 2 WINEPREFIX settings. Direct running by binfmt_misc cannot tell that X application in fact owns to alternative WINEPREFIX. Wine does not use extended Xattr to declare WINEPREFIX ownership on .exe files. No idea what you're talking about here. Really I would like to hear the real-world examples that require this feature. Like Mathieu, I've been using this feature to ease cross-compiling. Basically the broken state is a good time to patch up a security issue. Please explain why do you think that this is a security issue: ./foo.exe but this is not: wine foo.exe Anyway, if Debian wine maintainers decide that this feature is no longer desirable, then: 1) It should be documented in NEWS.Debian; 2) The /usr/bin/wine-auto interpreter should be properly removed from the binfmt-support database. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733556: Ok I think someone has this issue backwards.
I think you have this issue backwards.Wine project in fact recommends against using binfmt_misc with wine. Building wine from source has never made binfmt-misc entries. The binfmt_misc entries are something maintainers thought up as a good idea. Reasons why its an very wrong thing. 1 wine should not be run as root. There is no wrapper on binfmt_misc to make it fail in case of a .exe on root. Reason why wine should not run as root. Wine can run Windows viruses very effectively. Number 2 WINEPREFIX settings. Direct running by binfmt_misc cannot tell that X application in fact owns to alternative WINEPREFIX. Wine does not use extended Xattr to declare WINEPREFIX ownership on .exe files. So the fact it broken the question needs to be asked. Should this feature be removed and made only for those who wish to take the risk. Really I would like to hear the real-world examples that require this feature. binfmt_misc is not required by graphical environments on Linux since wine does register itself by the freedesktop mine types. From command line you will find xdg-open some.exe does in fact work. Just like wine some.exe works. Yes the missing WINEPREFIX inforamtion is a problem with xdg-open this is why running wine by shell script or .desktop file is recommend. Basically as far as the main wine project knows no end user has an use for binfmt_misc loading .exe files. So to them its one of those bright spark ideas by package makers without any consideration to security. If binfmt_misc exists with wine it should really be a independent package to the main wine package as the implementation of binfmt_misc does not come from the main wine project and it is a security risk that end users should opt in on not have to remember to opt out on. Basically the broken state is a good time to patch up a security issue. I also don't believe this bug is due a grave rating. Grave rating was the fact binfmt_misc worked with wine. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733556:
Just FYI, here is how to fix the current package: $ wget http://ftp.de.debian.org/debian/pool/main/w/wine/wine-bin_1.4.1-4_i386.deb $ dpkg-deb -x wine-bin_1.4.1-4_i386.deb bla $ sudo cp bla/usr/share/binfmts/wine /usr/share/binfmts $ sudo /usr/sbin/update-binfmts --import wine Enjoy -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
