Wine securityflaw: Protect against root

Shachar Shemesh wine-devel at sun.consumer.org.il
Sun Oct 27 08:31:25 CST 2002


Excuse me, but I don't think that any of these proposed methods will 
live up to any real malicious code. Personally, I believe we should make 
wine:
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.
>
>
>




More information about the wine-devel mailing list