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

[Guillaume SH]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-devel/attachments/20090129/f9d27a54/attachment-0001.htm