Dear friends and developers of WINE,
I've been using your application now for some time, and it works quite well yet. However, I found the mapping of Drive Z: to root, which seems a bit strange to me. I've also read some of your discussion on this topic, too. Personally, I'd consider this a maybe issue of security. Nowadays Linux users don't care as much about security as server admins would do. Alas, Linux being a multi-user system by tradition should take care of "normal" home desktop users trying to migrate from proprietary realms.
It would help a lot if WINE would do a more secure installation by default, but this is only my 2p.
(Maybe it's possible just to leave out the Z: mapping?)
Kind regards,
schollsky
On 7/23/06, schollsky@arcor.de schollsky@arcor.de wrote:
It would help a lot if WINE would do a more secure installation by default, but this is only my 2p.
(Maybe it's possible just to leave out the Z: mapping?)
My 2 cents: It's an ease-of-use thing. Yes, we should leave out the Z: mapping, but then you have to get the mappings for cd-rom's and the like Just Right.
If somebody gets passionate about this, and is willing to add lots of polish, it could be fixed. But it's hard, and not a core issue blocking further development, so it's kind of low priority. - Dan
Am Sonntag 23 Juli 2006 17:04 schrieb Dan Kegel:
On 7/23/06, schollsky@arcor.de schollsky@arcor.de wrote:
It would help a lot if WINE would do a more secure installation by default, but this is only my 2p.
(Maybe it's possible just to leave out the Z: mapping?)
My 2 cents: It's an ease-of-use thing. Yes, we should leave out the Z: mapping, but then you have to get the mappings for cd-rom's and the like Just Right.
If somebody gets passionate about this, and is willing to add lots of polish, it could be fixed. But it's hard, and not a core issue blocking further development, so it's kind of low priority.
Disabling the Z:\ drive won't help security because windows applications can still do Linux syscalls (int 0x80) which they can use do do anything native apps do, like accessing files outside wine drive mappings.
I think it's more important that Linux systems are set up properly, like secure access rights and unpriviledged user accounts. If the windows app is run as root it can't do more harm than destroying the home directory, which it can even do without a Z:\ drive entry.
Stefan Dösinger wrote:
Disabling the Z:\ drive won't help security
in THEORY...
because windows applications can still do Linux syscalls (int 0x80) which they can use do do anything native apps do, like accessing files outside wine drive mappings.
But in PRACTICE, it would help a lot to hinder total system destruction once viruses start running correctly on Wine.
(Especially for users like me, who always runs Wine as the root user ;-).)
On Mon, Jul 24, 2006 at 02:49:57PM +0200, Molle Bestefich wrote:
But in PRACTICE, it would help a lot to hinder total system destruction once viruses start running correctly on Wine. (Especially for users like me, who always runs Wine as the root user ;-).)
you complain about security in wine and run it as root? even if i have the strongest doubts, that there is need for running wine as root - at least do a chroot or use systraceorwhattheyarenamednowadays. it makes hardly sense to suggest security measures for wine while running it as root - this is like suggesting, that vi should no longer be able to modify files, because started as root your could modify every file on the system.
Christoph Frick wrote:
Molle Bestefich wrote:
But in PRACTICE, it would help a lot to hinder total system destruction once viruses start running correctly on Wine. (Especially for users like me, who always runs Wine as the root user ;-).)
you complain about security in wine and run it as root? even if i have the strongest doubts, that there is need for running wine as root
Hehe.
It won't work as non-root, and I could waste days finding out whatever's wrong with my X configuration (which is the default as it comes with Gentoo, btw).
I have a *lot* of much more productive ways that I can spend that time ;-).
at least do a chroot or use systraceorwhattheyarenamednowadays.
Hmm. Thanks for the tip.
it makes hardly sense to suggest security measures for wine while running it as root - this is like suggesting, that vi should no longer be able to modify files, because started as root your could modify every file on the system.
Granted, wine is as fucked as everything else when running as 'root', so it would seem like the wrong place to fix things.
OTOH, if sandboxing the rest of your Linux system from Windows bugs introduced through Wine is as easy as disabling drive Z: (and for the most part, it is!), then we should certainly make sure that it can be done and can be done easily.
Michael Stefaniuc wrote:
I guess Wine needs a patch to make it stop working as uid 0
And the point of fucking with people like this would be... The sheer fun of fucking with people that you don't happen to agree with? :-)
you complain about security in wine and run it as root? even if i have the strongest doubts, that there is need for running wine as root
It won't work as non-root, and I could waste days finding out whatever's wrong with my X configuration (which is the default as it comes with Gentoo, btw).
?! You're saying that you can't get wine to work for you as non-root? Do other X applications work for you as non-root?
Did you try that with a fresh "test" user?
Cheers, Kuba
Kuba Ober wrote:
?! You're saying that you can't get wine to work for you as non-root? Do other X applications work for you as non-root?
Can't remember, but my gut feeling is 'no'.
(It's probably something really simple too, I just don't have the time, energy nor do I even want to figure out how this crap works - for the time being, I'm not into X hacking, so for me it's a tool that should "just work", and if it doesn't, the worst I'm going to do about it is hate it real good.)
Did you try that with a fresh "test" user?
Yes.
Which all leads to nothing, as any windows application can test for and then invoke linux (or freebsd, or whatever) syscalls directly without wine ever knowing.
Yeah, but next to none of them actually do. The point was that removing drive Z: is an effective stopgap for a whole slew of existing malware because of that.
Nobody's saying that there isn't much better (or even perfect) ways to protect yourself, just that this might be appropriate for the time being for a whole lot of people.
(To get really obnoxious, not having sex with people in Africa won't protect you from HIV as well as a condome will, but in a lot of situations, it's easier to implement and it actually serves the purpose quite well.)
Do other X applications work for you as non-root?
Can't remember, but my gut feeling is 'no'.
(It's probably something really simple too, I just don't have the time, energy nor do I even want to figure out how this crap works - for the time being, I'm not into X hacking, so for me it's a tool that should "just work", and if it doesn't, the worst I'm going to do about it is hate it real good.)
I think that your X server works just fine. It's probably that you don't have your default desktop environment set up properly. There should be a configuration utility to set up just that.
Cheers, Kuba
On Monday 24 July 2006 13:25, Molle Bestefich wrote:
Kuba Ober wrote:
?! You're saying that you can't get wine to work for you as non-root? Do other X applications work for you as non-root?
Can't remember, but my gut feeling is 'no'.
Then it's really off-topic then. If you'd be willing to give me a regular clean user ssh account on that machine, I can try and figure things out. Just make the /var/log/*X* and /var/log/*x.org* readable by that user, and make /etc/X11/* writable. We can agree on some time so that I can open a text chat session to you and you could restart X as necessary. Just make sure you have nchat (or similar text chat) installed.
Besides, it may be something as simple as not having your windowing environment properly set up, as opposed to there being anything wrong with X server itself. Likely the window manager and the environment from xfce, kde or gnome doesn't start up.
Let me know off-list if you want to get it fixed.
Since it's ridiculous to get wine involved in your system's obious misconfiguration, I'm willing to fix it for you. In fact I only feel like doing it for you because it's so ridiculous to drag this problem onto this list as to be funny in an obscene way, if you get my idea ;)
Cheers, Kuba
Molle Bestefich wrote:
(It's probably something really simple too, I just don't have the time, energy nor do I even want to figure out how this crap works - for the time being, I'm not into X hacking, so for me it's a tool that should "just work", and if it doesn't, the worst I'm going to do about it is hate it real good.)
Why in the world would run Gentoo when you want something that 'just works'?
Gentoo is a great distribution but you are not its target audience. Go install Ubuntu or SuSE.
Dimi Paun wrote:
Fixing your X installation would do you a lot more good.
Not sure how much it would help though - I'm secretly also slightly hateful towards the concept of configuring and switching between two user accounts just to do daily work. It seems such a conceptually broken solution (beside from being a waste of my time).
What distro do you run?
Gentoo.
Joseph Garvin wrote:
Gentoo is a great distribution but you are not its target audience. Go install Ubuntu or SuSE.
Point taken. I like KDE better than Gnome, so Ubuntu is a bad fit. And the 5.04 installation CD completely hung my workstation when I tried it. SuSE could be a better fit. Then again, I compile sources often enough and I really do find that aspect of Gentoo convenient.
Ok, enough about my ridiculous setup already :)..
Kuba Ober wrote:
Besides, it may be something as simple as not having your windowing environment properly set up, as opposed to there being anything wrong with X server itself. Likely the window manager and the environment from xfce, kde or gnome doesn't start up.
Just tried. You're absolutely right. A few months ago, X wouldn't even start as non-root, but I've since upgraded to X.org 7 and KDE 3.5, and today it starts. The only problem seems to be that non-root boots into twm + xclock + xterm instead of KDE.. Nice crystal balling :-).
Let me know off-list if you want to get it fixed.
I have no issue with giving you SSH access, but I'd hate to be wasting your time more than I am already. You're obviously much more knowledgeable than I am, I bet you could do seriously cool things with the time you'd be wasting on me.
(Point taken about the list noise, btw. I'm trying to be polite and answer people's questions, and at the same time not expand the subject since I know we're deeply off-topic by now. I do feel bad about that, but there's no way right now to both answer questions and keep things on-topic. A "move this conversation to chit-chat room" feature for mailing lists would be nice...)
n0dalus wrote:
I mean, is there a way for wine to stop applications it runs from making those syscalls while still being able to make them itself?
Hook the interrupt perhaps?... Granular security through SELinux maybe?...
Hi,
What distro do you run?
Gentoo.
I am a Gentoo user too, and I never had problems with running as non-root. the system starts up kdm at startup and I can log in there as a normal user which I use for everyday work, wine development, running windows apps and everything else. I never had any problems with it, and I can't remember setting anything special
On 7/25/06, Molle Bestefich molle.bestefich@gmail.com wrote:
(Point taken about the list noise, btw. I'm trying to be polite and answer people's questions, and at the same time not expand the subject since I know we're deeply off-topic by now. I do feel bad about that, but there's no way right now to both answer questions and keep things on-topic. A "move this conversation to chit-chat room" feature for mailing lists would be nice...)
Just thought I'd go extremely off-topic on this one and point out (yea yea huge groan from everyone lol) that this is yet another argument that I think a forum would fix.....................
Molle Bestefich wrote:
Point taken. I like KDE better than Gnome, so Ubuntu is a bad fit. And the 5.04 installation CD completely hung my workstation when I tried it.
Kubuntu is the same distro just using KDE as the default desktop, and the latest version of Ubuntu/Kubuntu, Dapper, has improved hardware support. I'd give it another go ;)
Molle Bestefich wrote:
you complain about security in wine and run it as root? even if i have the strongest doubts, that there is need for running wine as root
It won't work as non-root,
Wine works always as non-root.
and I could waste days finding out whatever's wrong with my X configuration (which is the default as it comes with Gentoo, btw).
I'm using wine with Ubuntu 5.04 without Problems.
Your System is really broken / wrong configured, when wine does not work as normal user.
fu****g : This is not a Mailing-List for such words
Monday, July 24, 2006, 10:00:44 AM, Molle Bestefich wrote:
Christoph Frick wrote:
you complain about security in wine and run it as root? even if i have the strongest doubts, that there is need for running wine as root
Hehe.
It won't work as non-root, and I could waste days finding out whatever's wrong with my X configuration (which is the default as it comes with Gentoo, btw).
That just shows how much you know your system. Wait, do you even know that you running Linux and not winbloze?
I have a *lot* of much more productive ways that I can spend that time ;-).
Of course bitch on wine-devel about your ignorance and inability to learn. Then write more off-topic stuff. Then bitch some more using words that 10 year olds will feel really proud to say in the public (when no one knows who they are).
Granted, wine is as fucked as everything else when running as 'root', so it would seem like the wrong place to fix things.
Then why are you running everything as root? Or right I forgot. It's not root, it's Administrator...
I think the only cure for you that you will understand is 'rm -rf /' (man rm for what it's doing). Then unplug that thing that you just worked with, and throw it out the window.
Since you don't have basic understanding of what the hell that thing is anyway. Why bother?
Or better then that go and buy xbox. It can play games too.
Vitaliy.
On 7/24/06, Vitaliy Margolen wine-devel@kievinfo.com wrote:
Or better then that go and buy xbox. It can play games too.
Vitaliy.
I wouldnt advise that, because an xbox can run linux too, and since the original xbox runs on PC hardware, i wouldbt be at all surprised to see someone try to get wine working on it.. in which case they would come here for help (groan)..
No trolling on the wine-devel mailing list please. I got in deep shit for that, but you are a rather respected member of the Wine community, and to lose that respect over a simple flame would be ironic.
And it seems the other guy is trolling himself, but did you not see the sign? "Do not feed the trolls."
Vitaliy Margolen wrote: < Vitaliy's trolling has been cut >
Molle Bestefich wrote:
Stefan Dösinger wrote:
Disabling the Z:\ drive won't help security
in THEORY...
because windows applications can still do Linux syscalls (int 0x80) which they can use do do anything native apps do, like accessing files outside wine drive mappings.
But in PRACTICE, it would help a lot to hinder total system destruction once viruses start running correctly on Wine.
(Especially for users like me, who always runs Wine as the root user ;-).)
That's plain wrong. I guess Wine needs a patch to make it stop working as uid 0 ...
bye michael
On 7/24/06, Michael Stefaniuc mstefani@redhat.com wrote: [cut]
That's plain wrong. I guess Wine needs a patch to make it stop working as uid 0 ...
Some interesting "security features" could be: * Built-in option to execute Wine in a jail, like using chroot command, over a WINEPREFIX; * Block root or a warning when doing this as an oficial option at execution or compilation time; * A interative warning or something like "firewall popup warning" about apps running under Wine accessing files outside of the WINEPREFIX.
My 2 cents.
Augusto Arcoverde da Rocha
Augusto Arcoverde da Rocha wrote:
Some interesting "security features" could be:
- Built-in option to execute Wine in a jail, like using chroot
command, over a WINEPREFIX;
- Block root or a warning when doing this as an oficial option at
execution or compilation time;
- A interative warning or something like "firewall popup warning"
about apps running under Wine accessing files outside of the WINEPREFIX.
Wine's dlls and libraries all exist outside of WINEPREFIX, so doing the above would mean that Wine wouldn't be able to open it's own builtin dlls.
You're trying to turn Wine into something it isn't. Use Qemu, Xen or some other virtualization solution if you don't trust the programs you want to run.
Mike
That's plain wrong. I guess Wine needs a patch to make it stop working as uid 0 ...
Some interesting "security features" could be:
[. . .]
Which all leads to nothing, as any windows application can test for and then invoke linux (or freebsd, or whatever) syscalls directly without wine ever knowing.
I.e. if you have a rogue windows application, wine won't help you. It's just as if you had a rogue native application. Any notion that it's otherwise has no basis in fact. Running something under wine is the same as running a native application, from the security viewpoint.
If you ordinarily sandbox untrusted 3rd party native applications, I'm sure you'd do the same for wine. If, OTOH, you run random 3rd party native code as root, then running wine as same won't matter much.
Cheers, Kuba
Michael Stefaniuc wrote:
Molle Bestefich wrote:
Stefan Dösinger wrote:
Disabling the Z:\ drive won't help security
in THEORY...
because windows applications can still do Linux syscalls (int 0x80) which they can use do do anything native apps do, like accessing files outside wine drive mappings.
But in PRACTICE, it would help a lot to hinder total system destruction once viruses start running correctly on Wine.
(Especially for users like me, who always runs Wine as the root user
;-).) That's plain wrong. I guess Wine needs a patch to make it stop working as uid 0 ...
D'accord.
On 7/24/06, Stefan Dösinger stefandoesinger@gmx.at wrote:
Disabling the Z:\ drive won't help security because windows applications can still do Linux syscalls (int 0x80) which they can use do do anything native apps do, like accessing files outside wine drive mappings.
Is there a way to disable this as well?
n0dalus.
"n0dalus" n0dalus+wine@gmail.com wrote:
On 7/24/06, Stefan Dösinger stefandoesinger@gmx.at wrote:
Disabling the Z:\ drive won't help security because windows applications can still do Linux syscalls (int 0x80) which they can use do do anything native apps do, like accessing files outside wine drive mappings.
Is there a way to disable this as well?
If you carefully re-read the above conversation and clearly recognize Wine as a native application, then the answer is yes: just stop using Wine along with other native applications.
On 7/25/06, Dmitry Timoshkov dmitry@baikal.ru wrote:
Disabling the Z:\ drive won't help security because windows applications can still do Linux syscalls (int 0x80) which they can use do do anything native apps do, like accessing files outside wine drive mappings.
Is there a way to disable this as well?
If you carefully re-read the above conversation and clearly recognize Wine as a native application, then the answer is yes: just stop using Wine along with other native applications.
I mean, is there a way for wine to stop applications it runs from making those syscalls while still being able to make them itself?
n0dalus.
"n0dalus" n0dalus+wine@gmail.com wrote:
I mean, is there a way for wine to stop applications it runs from making those syscalls while still being able to make them itself?
No, and the reason "why" already has been pronounced.
On Sun, Jul 23, 2006 at 04:28:09PM +0200, schollsky@arcor.de wrote:
Dear friends and developers of WINE,
I've been using your application now for some time, and it works quite well yet. However, I found the mapping of Drive Z: to root, which seems a bit strange to me. I've also read some of your discussion on this topic, too. Personally, I'd consider this a maybe issue of security. Nowadays Linux users don't care as much about security as server admins would do. Alas, Linux being a multi-user system by tradition should take care of "normal" home desktop users trying to migrate from proprietary realms.
It would help a lot if WINE would do a more secure installation by default, but this is only my 2p.
(Maybe it's possible just to leave out the Z: mapping?)
rm ~/.wine/dosdevices/z:
You can also adjust the "wineprefixcreate" script not to create it anymore.
Ciao, Marcus
Hi Marcus,
you wrote:
(Maybe it's possible just to leave out the Z: mapping?)
rm ~/.wine/dosdevices/z:
You can also adjust the "wineprefixcreate" script not to create it anymore.
as we've heard from our Austrian colleague, this is not improving sec (which was a freshening shock for me). Furthermore, on this machine it's impossible to remove the softlink mapping to Z:. It points to "//". This was not done manually nor intentionally. So I wondered wether this is part of WINE's normal behaviour or something different.
Kind regards,
schollsky
On Mon, Jul 24, 2006 at 11:25:17AM +0200, schollsky@arcor.de wrote:
Hi Marcus,
you wrote:
(Maybe it's possible just to leave out the Z: mapping?)
rm ~/.wine/dosdevices/z:
You can also adjust the "wineprefixcreate" script not to create it anymore.
as we've heard from our Austrian colleague, this is not improving sec (which was a freshening shock for me). Furthermore, on this machine it's impossible to remove the softlink mapping to Z:. It points to "//". This was not done manually nor intentionally. So I wondered wether this is part of WINE's normal behaviour or something different.
Since the symlink is in a directory controlled by the user, the user should be able to remove it. If not, something is broken.
ls -la ~/.wine ls -la ~/.wine/dosdevices
Ciao, Marcus
Marcus Meissner wrote:
as we've heard from our Austrian colleague, this is not improving sec (which was a freshening shock for me).
Since the symlink is in a directory controlled by the user, the user should be able to remove it. If not, something is broken.
ls -la ~/.wine ls -la ~/.wine/dosdevices
Ciao, Marcus
Is there a Linux hardening guide that we can recommend that people use to make their systems safe?
Jeff
On Mon, Jul 24, 2006 at 08:58:05PM +1000, Jeff Latimer wrote:
Marcus Meissner wrote:
as we've heard from our Austrian colleague, this is not improving sec (which was a freshening shock for me).
Since the symlink is in a directory controlled by the user, the user should be able to remove it. If not, something is broken.
ls -la ~/.wine ls -la ~/.wine/dosdevices
Ciao, Marcus
Is there a Linux hardening guide that we can recommend that people use to make their systems safe?
?
WINE is for executing binary programs the user downloads.
You can only make it safer be deinstalling. ;)
Ciao, Marcus
Le lundi 24 juillet 2006 à 11:25 +0200, schollsky@arcor.de a écrit :
Hi Marcus,
you wrote:
(Maybe it's possible just to leave out the Z: mapping?)
rm ~/.wine/dosdevices/z:
You can also adjust the "wineprefixcreate" script not to create it anymore.
as we've heard from our Austrian colleague, this is not improving sec (which was a freshening shock for me). Furthermore, on this machine it's impossible to remove the softlink mapping to Z:. It points to "//". This was not done manually nor intentionally. So I wondered wether this is part of WINE's normal behaviour or something different.
Try: rm ~/.wine/dosdevices/z:
-
Augusto Arcoverde da Rocha -
Christoph Frick -
Dan Kegel -
Detlef Riekenberg -
Dmitry Timoshkov -
Jeff Latimer -
Jonathan Ernst -
Joseph Garvin -
Kuba Ober -
Marcus Meissner -
Marcus Meissner -
Michael Stefaniuc -
Mike McCormack -
Molle Bestefich -
n0dalus -
schollsky＠arcor.de -
Segin -
Stefan Dösinger -
Tom Booker -
Vitaliy Margolen