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

On Thu, 29 Jan 2009 14:07:13 -0500, Alex Villací­s Lasso
 wrote:
> 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.
>
> How would your proposal work in this case? Instead of the installer 
> working normally (from the point of view of the user), wine now would 
> show an unexpected popup with some message. Most probably the user won't 
> read the message. Instead, he or she will complain that wine now has a 
> regression and refuses to install program XYZ.
>
> Regarding "encouraging best practices", this won't work for the zillion 
> Windows programs already written for Windows that people might want to 
> try under Wine. Especially abandonware. My personal opinion is that this 
> proposal would be more annoying and helpful, and if ever implemented, it 
> should be used as a debugging tool (disabled by default), rather than 
> something the user sees. Maybe this could be implemented as a trace 
> enabled by WINEDEBUG.

Hi, I've been lurking on this list for awhile, thinking about how I could
contribute to Wine.

I wanted to weigh in because I think this overall proposal is on the right
track. Graceful handling of errors and crashes would provide a better user
experience and potentially help increase the adoption of Wine by more
casual users.

I don't know much about application fault/exception handling, but couldn't
Wine just install its own top-level fault handler on each Wine
thread/process? That way, each API call in Wine can mimic the crash
behavior of Windows to satisfy applications like InstallShield, but if the
application doesn't handle the exception, the global Wine handler will pick
it up and handle it gracefully.

Please excuse me if I am totally off track here.