A. Not require root
B. As secure on it's own as possible (i.e. - not open to any problems not introduced by the hosted program).
These two should allow securing Wine to the point where it is up to the packagers and to the people calling Wine to do their tasks, giving them the tools to do so. I don't believe we should, or even that we CAN, solve security problems introduced by insecure deployment.
The only thing is that we should make secure deployment as easy as possible, not that we should make insecure deployment impossible. The later is both unobtainable, and will hurt usability.
Shachar
David D. Hagood wrote:
P. Christeas wrote:
Write a segment of code that will abort wine, if it is run as root (that is,
just before wine starts anything). This piece of code should only be
explicitly disabled in the 'configure' script. That way, only a
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.
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).
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.
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.
