Wine securityflaw: Protect against root

[Eric Pouech]

> I slightly disagree - I think the thing to do would be to have wine not
> run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is
> set, AND THEN pop up a dialog box that requires confirmation before
> continuing.
does rm have such an option ? rm doesn't, so I don't see any reason for
this code bloat
if you want to be paranoid (or you distro want to be), do it in wine
script (or in the .winewrapper extension)

> I would ALSO suggest that wine check the execute bit on the application
> being run - the recent incident with Klez running under Wine would not
> have happened (I think) if wine would not run that which is not marked
> with the -X bit (unless, again, a command line parameter is supplied,
> and a warning dialog is confirmed).
that could bring some issues while trying to run a native executable
from a mounted FAT driver (without the proper umask option for mount)
(this could be circumvented by a drive configuration option in wine, but
that would be a bit tricky to set for the average user)

> Since I know of no mail client for Linux that would set the X bit on an
> attachment, this would help protect users from themselves, while
> allowing those that need to be able to take the risks to do so.
IMHO (regarding Klez), the main issue is the mail client not wine. It
should protect/warn the user about this, not forward the blame on others

> And as for making "/" available as a Wine drive - how about creating a
> tool that would allow you to add or remove drive mappings at run time?
> So that if I find that I really do need /usr/foo/bar/baz available to
> Wine, I can run a program that tells wineserver to add that as drive Q:
> for now.
I think this a more interesting alternative. People did start working on
that (especially for SMB shares mounting)
A+