[pkg-wine-party] Bug#733556: Ok I think someone has this issue backwards.
oiaohm at gmail.com
Thu Mar 6 00:14:28 UTC 2014
On Tue, Mar 4, 2014 at 10:51 PM, Jakub Wilk <jwilk at debian.org> wrote:
> * Peter Dolding <oiaohm at 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
> 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
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.
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.
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
> 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:
> 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.
More information about the pkg-wine-party