A proposal for increased security in wine - respecting previously expressed needs

[Rob Shearman]

2009/1/29 Alex Villací­s Lasso <a_villacis at palosanto.com>:
> Guillaume SH escribió:
>> Hi wine community,
>>
>> I took some time for reflexion following the thread "A step in the wrong
>> direction, in an ocean of steps in the right direction" and to the
>> explanations some of you kindly exposed to me.
>>
>> As a follow-up I am making a proposal.
>>
>> A - The proposal
>>
>>   A1 - The core proposal
>>
>>      All function callable from outside wine should implement, as the first
>> task they perform(1), a sanity parameter check. This check
>>      hasn't to be systematic, only really used parameters should be checked
>> and only checks assuring those parameters can be safely used
>>      the way they are in the function implementation (or in a function
>> called by it). Other check are superfluous and must be discarded.
>>
>>      So to decline the proposal operationally, I will take an example(2) :
>>
>>      BOOL WINAPI GetOverlappedResult(HANDLE hFile, LPOVERLAPPED
>> lpOverlapped, [...])
>>
>>      if ( lpOverlapped == NULL )
>>      {
>>         #Call the function ExitWineCleanlyAndAdvertiseUser
>>      }
>>
>>
>>     This call being justified by the statement, following some lines later :
>> status = lpOverlapped->Internal;
>>
>>
>>     The function ExitWineCleanlyAndAdvertiseUser being something like that :
>>
>>     <Result to be determined> ExitWineCleanlyAndAdvertiseUser <Parameters to
>> be determined>
>>
>>        #1 - Advertise user outputting a message, for example : "The
>> application you used present a defect. Using it directly expose you to some
>>             security issue and indirectly expose others users to some other
>> security issue."
>>
>>        #2 - Cleanly release all still allocated resources
>>
>>        #3 - Cleanly exit wine
>>
>>
>>   A2 - offering flexibility
>>
>>      As I have understood that wine community is willing to be able to run
>> all applications written for a Windows platform,
>>      even those relying on the worse behaviours of windows, I will propose
>> too to add a registry key for the purpose of enabling / disabling
>>      wine "safe" mode.
>>      In this case it would make sense that "safe" mode is the default, with
>> possibility to fall-back to "unsafe" mode when needed.
>>
>> B - Advantages / Drawbacks to the proposal
>>
>>     Drawback of this solution I can think of are :
>>     1 - It is contrary to the current consensus
>>     2 - It implies a lot of work (even if this can be done bit by bit over a
>> long period time, direction is what matters here)
>>     3 - Detailed implementation of what I presented may very well not be as
>> simple as I imagine, or even impossible
>>     4 - Maybe all the reasons have not been expressed in the previous
>> thread, thus not considered here
>>     5 - It can go against the interest of the author of those apps relying
>> on Windows's bad behaviors (large firms for example)
>>     6 - It doesn't cover all security issue in wine and it doesn't cover at
>> all security issue in the calling app
>>     7 - Performance drop-down may be expected (0,01%, 0,1%, 1%, more ? I
>> don't know how to evaluate)
>>
>>     Advantage of this solution I can think of are :
>>     1 - Top-notch level of service to user : I can be informed when I use an
>> unsafe software !
>>     2 - Encouragement to software industry : I must provide some clean and
>> safe software or wine can judge me "unsafe" (=promoting "best-practices")
>>     3 - Wine is better from it, so people will have a better opinion of wine
>>     4 - Goal reached by wine are far beyond "Windows behaviours on free-OS
>> platform"
>>     5 - Wine is safer so more people will want to use it and to promote its
>> usage
>>
>>
>> I think I will go no further than this proposal, so I leave the rest to you,
>> from simply ignoring it to demonstrate me than I'm wrong or applying a
>> variation,
>> Guillaume
>>
>> (1) TRACE, variable declaration or other task may come before though
>> (2) Please don't argue about the coding style, I am not a technical expert
>> (unlike you) and it would be off-topic
>>
>>
> I think I remember a discussion about a particular bug in which some
> version of an installer (InstallShield?) refused to work correctly
> because the wine version of one API call was checking a pointer
> parameter against NULL and returning an error code instead of crashing.
> If I recall correctly, it turned out that the installer *expected* the
> crash, and depended on the fault handler executing some code for its
> correct operation. So the NULL check was removed, the API now crashes
> with the invalid pointer (exactly like native) and that installer now
> works correctly. Maybe somebody who was involved in the actual fix can
> dig up a pointer to the relevant thread.

http://www.winehq.org/pipermail/wine-devel/2006-July/049830.html
http://bugs.winehq.org/show_bug.cgi?id=5384

-- 
Rob Shearman