How can I detect WINE from my program?

Open forum for end-user questions about Wine. Before asking questions, check out the Wiki as a first step.
Forum Rules
Sjors Gielen

How can I detect WINE from my program?

Post by Sjors Gielen » Wed Jun 03, 2009 9:23 am

This is a good point. But you can't force developers to do that, also because there exists easy workarounds. Running a native binary, reading the environment. It's not that hard, maybe unreliable.
Why not cooperate? Make an API call like "bool IsWineBugFixed(int bugnr);". That function will read from a .conf/inf file that is updated at each wine release. Until the bug is fixed the Windows code will execute in custom way else it will run in a native way.
IsWineBugFixed() sounds like *totally* the wrong way around. Let it be
this way: just assume the bug is fixed, report it at Wine (with test
cases or even patches), and your program will work once the bug is
fixed. Until then, put a web page up or whatever saying "This program
does not work on Wine because of <a>bug 1234</a>" or "This program does
not work on Wine, unless you compile Wine yourself with <a>this
patch</a> compiled in".

Wine developers aren't, and shouldn't be, interested in hacky solutions
to get as much Windows programs as possible running on Wine; they are
interested in making Wine look like Windows as much as possible (that
coincidentally has the result of Windows programs working on Wine). The
only reason Wine is so great right now is because of that attitude.
Therefore, I also don't think they will ever implement *anything* like
an isWineBugFixed or isWine or whatever - it is not their goal, not
their way of "fixing" things, and it shouldn't be.

It takes less time to write a good test case that shows different
behavior in Wine than in native Windows, than it takes to implement a
workaround, maintain it, and remove it later
but-only-if-wine-version-is-foo (and then again, there's no reliable way
of checking that). Implementing Wine workarounds only makes the problem
worse in the long term, fixing (or even reporting) bugs in Wine makes
the problem *disappear forever*.

Sjors

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-us ... chment.pgp>

andreaplanet
Level 1
Level 1
Posts: 5
Joined: Thu May 28, 2009 4:54 pm

Re: How can I detect WINE from my program?

Post by andreaplanet » Wed Jun 03, 2009 11:03 am

Sjors Gielen wrote:IsWineBugFixed() sounds like *totally* the wrong way around.
Ok, let's forget that function. Was just an idea, no need for it.

And I understand the viewpoint that Wine
- want to make applications looks like Windows
- doesn't want to use hacks to make more Windows programs run (better)

But since more than one developer here wants a different behaviour for his application (see my previous message) we only ask for a simple "getNativeOS" function. Then it's our trouble to handle the wanted customizations (in my case the use of the native Finder style for Mac OS X and the native Nautilus style for Linux to handle the file dialog boxes (just an example). I want a more user-friendly application and not an exact copy of Windows.

Also is it possible to run always own distributed native linux/mac binaries even with a hardened Linux sandbox?

austin987
Wine Developer
Wine Developer
Posts: 2383
Joined: Fri Feb 22, 2008 8:19 pm
Contact:

How can I detect WINE from my program?

Post by austin987 » Wed Jun 03, 2009 11:08 am

On Wed, Jun 3, 2009 at 11:03 AM, andreaplanet <wineforum-user@winehq.org> wrote:
Sjors Gielen wrote:
IsWineBugFixed() sounds like *totally* the wrong way around.
Ok, let's forget that function. Was just an idea, no need for it.

And I understand the viewpoint that Wine
- want to make applications looks like Windows
- doesn't want to use hacks to make more Windows programs run (better)

But since more than one developer here wants a different behaviour for his application (see my previous message) we only ask for a simple "getNativeOS" function. Then it's our trouble to handle the wanted customizations (in my case the use of the native Finder style for Mac OS X and the native Nautilus style for Linux to handle the file dialog boxes (just an example). I want a more user-friendly application and not an exact copy of Windows.
Native dialog boxes aren't allowed, many programs depend on certain
nuances of the native dialog boxes.
Also is it possible to run always own  distributed native linux/mac binaries even with a hardened Linux sandbox?
Not sure what you mean here.

--
-Austin

andreaplanet
Level 1
Level 1
Posts: 5
Joined: Thu May 28, 2009 4:54 pm

Re: How can I detect WINE from my program?

Post by andreaplanet » Wed Jun 03, 2009 11:18 am

austin987 wrote:Native dialog boxes aren't allowed, many programs depend on certain
nuances of the native dialog boxes.
We don't ask for native dialog boxes, it's against the Wine viewpoint, and this is accepted.
We ask for a simple getNativeOS function. So that we can use our own native linux/mac binary to do whatever we want for a more user-friendly application.
austin987 wrote:
Also is it possible to run always own  distributed native linux/mac binaries even with a hardened Linux sandbox?
Not sure what you mean here.
oiaohm said that with a hardened Linux/Sandbox it's not possible to run 'other native binaries', is this true also for my own distributed native linux binary or only for the binaries outside the C: symlink?

austin987
Wine Developer
Wine Developer
Posts: 2383
Joined: Fri Feb 22, 2008 8:19 pm
Contact:

How can I detect WINE from my program?

Post by austin987 » Wed Jun 03, 2009 11:25 am

On Wed, Jun 3, 2009 at 11:18 AM, andreaplanet <wineforum-user@winehq.org> wrote:
austin987 wrote:
Native dialog boxes aren't allowed, many programs depend on certain
nuances of the native dialog boxes.
We don't ask for native dialog boxes, it's against the Wine viewpoint, and this is accepted.
We ask for a simple getNativeOS function. So that we can use our own native linux/mac binary to do whatever we want for a more user-friendly application.
If you're running on Wine, it's going to report the native OS as
whatever Windows version it is emulating.

If you want to use a native linux/mac binary, then do so, you don't
need Wine to do this.

I think what you'd like to do is have your windows program, but bundle
it with some 'native' programs, and selectively call it based on which
OS it is on? If so, distribute a version for each OS you want, have it
run as a native program, and have the windows binary bundled as a
dependency. No need to detect anything from wine.
austin987 wrote:
Also is it possible to run always own  distributed native linux/mac binaries even with a hardened Linux sandbox?
Not sure what you mean here.
oiaohm said that with a hardened Linux/Sandbox it's not possible to run 'other native binaries', is this true also for my own distributed native linux binary or only for the binaries outside the C: symlink?
I think he meant that for some distributions, with e.g., AppArmor, you
can't run native applications from wine, and wine is only allowed
access to files under its C drive. What you are/are not allowed to run
under such systems depends on the configuration.

--
-Austin

Sjors Gielen

How can I detect WINE from my program?

Post by Sjors Gielen » Wed Jun 03, 2009 11:38 am

andreaplanet wrote:
And I understand the viewpoint that Wine
- want to make applications looks like Windows
I didn't literally mean "make applications look like Windows", I meant,
from a program's point of view, make the Wine API and functions work
exactly the same as they do in Windows, i.e. make the Wine layer totally
transparent.
- doesn't want to use hacks to make more Windows programs run (better)
Right. :)

The point of detecting Wine to make an application more user-friendly is
moot, in my opinion. It sounds good, but without detecting Wine an
application can be just as user-friendly as it is on Windows, and I
think it will be unmanageable to integrate a Windows application with,
for example, Gnome or KDE specifics, only for when it's running on Wine.
What Austin just said makes a lot of sense:
I think what you'd like to do is have your windows program, but bundle
it with some 'native' programs, and selectively call it based on which
OS it is on? If so, distribute a version for each OS you want, have it
run as a native program, and have the windows binary bundled as a
dependency. No need to detect anything from wine.
That makes for a little bit of "detecting wine". Though of course, this
leaves the option of workarounding Wine bugs wide open, with all its
complications.
...Or, of course, port the application to native Unix/POSIX (with Gtk or
KDE, for example) all the way. ;-)

Sjors

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-us ... chment.pgp>

oiaohm
Level 8
Level 8
Posts: 1020
Joined: Fri Feb 29, 2008 2:54 am

Post by oiaohm » Wed Jun 03, 2009 9:49 pm

andreaplanet
So everyone who want to detect Wine must create his own exe.so? Ok, but if it is hardened through a sandbox then still can I run it? With a sandbox can I run a native linux binary distributed together with my application?
Reason exe.so are loaded by the wine loader. Same as your .exe if sandbox blocks the wine loader exe's of either form will not load so for wine to work it has to allow it. Now wine loader on the other hand can be set to refuse it. You can provide users with instructions to get around that.

AppArmor no. Selinux and smack harded yes. Selinux and smack can rule out program from loading other native programs completely with wine. Unless Selinux or smack approves you program to run particular native programs it cannot under hardened this even applies to native programs. Really makes attacking linux servers that are hardened fully pain in ass. Just coping in a elf file and trying to run it on a hardened system just sets off the alarms. To be correct selinux or smack can take ext-ream offense to it and terminate a program for attempting to do something it did not approve.


Selinux can also restrict the native .so files your programs can talk to. So if wine does not use a .so file and you decide to reach out and use something wine does not use you can almost bet in a hardened system you just got the application killed.

Selinux or smack when it terminates a program will not give program notice that it is doing so. It will just simply clean the program from memory. Its not something you want happening half way threw a write. Linux's hardened are a complete different game to windows. Linux does not take the soft method of answer you were not approved to do that. Simply just kills the program.

Yes Linux systems can have a hitman standing over your shoulder waiting to take your application out.

exe.so must only be Dependant on win32 dlls provide by wine and the right platform not to risk being blocked by a sandbox. Even probing can get touchy if wine passes a wrong platform elf to system because it don't id as a exe.so selinux and smack can kill application.

Sandboxed to hell. There is no way out. This is why I am saying it is better to tell the user and provide a wine tickbox and the like so user ticks wine and you can include like this program will use the following extra native parts please make sure wine/application has secuirty permissions to use them. Anything native person sandboxed many need to turn off. Also the reason why you might have to provide more than 1 workaround methods. Ie one using replacement win32 dlls and one using native parts. Reason why I keep pointing to the installer.

The difference dealing with a OS who secuirty system can truly work and has the mind that a harmless program killed by mistake is better than letting a harmful program pass.

By the way AppArmor is a complete joke of a mandatory access control system. Its not included in main line kernel because its file access controls can be bypassed. Someone really need to update it to support the secure path based system provided in 2.6.29 and on.

Bug numbers sound fine in theory. Until you wake up Wine bugzilla has been compacted 6 times so far. Closed bugs removed and new bugs give there bug numbers. Yes wine recycles bug numbers.

One of the open bugs is to try to make wine pull theming from user desktop and make wine look as close as native without breaking application compatibility. Wine really does not want to make applications in wine look like windows. Its just side effect from not being able to join the theming engines up.

oiaohm
Level 8
Level 8
Posts: 1020
Joined: Fri Feb 29, 2008 2:54 am

Post by oiaohm » Wed Jun 03, 2009 10:11 pm

Also by asking you can ask to run wine itself native with the wine --version flag to find out what version wine you have.

There is a good detect path using person behind the keyboard. Avoid person behind keyboard. You are playing with fire. Its a Linux system secuirty is out to get your program. That is the way you have to treat it.

Vincent Povirk

How can I detect WINE from my program?

Post by Vincent Povirk » Wed Jun 03, 2009 11:32 pm

On Mon, May 25, 2009 at 8:39 AM, oiaohm<wineforum-user@winehq.org> wrote:
If wine is reliability detectable this can be used by virus writers to attack host OS. Problem is for support wine would have to expose wine version and host OS reason some bugs are particular to like Mac OS or Linux or BSD... Once you know the host OS you can code to syscall the hosting OS and attack it. Downside of giving it up is cross platform viruses become simpler.
If Wine is running on Linux, it can always be detected by making Linux
syscalls. Wine cannot fix this. And of course if you're going to code
to syscalls, you can always detect the os by trying them and seeing
what happens. On Windows you'd just get an exception, which can easily
be caught.

ANY security provided by Wine is security by obscurity because the
program can do anything the underlying libraries can do.

Claiming that Wine provides some kind of sandboxing or other security
is dishonest, and using it as such is dangerous. If you want a
sandbox, use something that provides real security.

If an OS is applying security to Wine beyond what would be applied to
a normal program, that is completely different and irrelevant to the
question of whether detecting Wine should be possible/easy.

On Mon, Jun 1, 2009 at 2:35 AM, majkl<wineforum-user@winehq.org> wrote:
Its regarding UpdateLayeredWindow() function and transparency of the window. The problem is, that wine cannot show the window that uses alpha channel to specify transparency level for its every pixel.
This is hard, and at best when it is implemented it can only really
work with a compositing window manager.

I think in this case it's best to work around the bug. It would be
better if you could detect the failure directly rather than check for
Wine (so that if it is fixed, your program will work better), but I
can't think of a reasonable way to do this.

I would ask that you make sure the user has a way to disable any
wine-specific hacks. I don't think it's terribly important what the
default is. utorrent has an "enable wine hacks" setting that is
default on in Wine, and I think this is fine.

On Wed, Jun 3, 2009 at 6:21 AM, andreaplanet<wineforum-user@winehq.org> wrote:
First you say it is wrong to detect Wine, now you say let the user detect Wine (choose on which OS you are running).
Every developer have to write that question, save that info somewhere in the registry or a INI file. What a duplication.
Honestly a simple API call for everyone would be much easier without bothering the end-user.
As a end-user I would ask myself "isn't the program intelligent enough to detect on what system it is running?"
...
For example personally I want that my application use the native Open File Dialog and not the ugly default windows open file dialog. By reading the currently running OS I can run a specified native executable/library that offer this feature and interact with the EXE application through a pipe for example. The Wine community will refuse to use such a hack because it changes the natural behaviour of the Windows environment. And I want this change only for my own application, so that other applications will run without problems. Here a reason why a simple API to let me know the name of currently OS is welcome, and it should work both at least on Windows, Linux and Mac OS X.
I would be in favor of the creation of such API calls. Wine could
include (or someone could write one separately using winelib) a
library that exports a function that tells the calling program the
Wine version. It could also have functions to run a native filechooser
if it's available; this is a perfectly reasonable thing to implement.

With such a library, saying to the program "I am not Wine" is as easy
as disabling the library. We already have environment variables and
registry settings for doing this.

Vincent Povirk

Stefan Kuhr
Newbie
Newbie
Posts: 4
Joined: Sun May 31, 2009 10:27 am

How can I detect WINE from my program?

Post by Stefan Kuhr » Thu Jun 04, 2009 2:31 pm

I would really like to second almost everything that andreaplanet wrote, but for additional, different reasons. I work for a company that still supports for some old, not yet retired products, Windows 95 2nd edition up to Windows 7 now with latest and greatest builds. We heavily rely on a custom log file infrastructure that our support personnel uses to analyze what's going on on customer sites. We are talking about a product that runs on dozens of millions of corporate desktops and servers world wide, 24x7x365. As long as an app of ours will not be able to write to its log file, that it runs on Wine, instead of, say XP, no support personnel of ours will be able to distinguish real Windows XP from Wine's "illusion" of Windows XP, so we will never be able to support Wine, period, end of story.

In a private project of mine I currently follow this approach: Users will have to specify the Wine version they are running, as a command line parameter. If they don't, the app will either not work or crash with current versions of Wine. There is no other way, otherwise I cannot work around limitations that Wine has, but I believe will not get fixed any time soon, given the fact that I submitted bug reports almost a year ago. It would be a helluva lot easier if there were a way to get the Wine version and let my app apply its compatibility code paths with a priori knowledge it has about certain Wine versions. Hey, I have to do the same thing for Windoze9x vs. NT vs. Windows 2000 vs. XP vs. W2K3 server vs. ..... why does Wine make it so hard for me to help my apps make the best use of it?


--
Stefan

Alexandre Julliard

How can I detect WINE from my program?

Post by Alexandre Julliard » Fri Jun 05, 2009 4:01 am

"Stefan Kuhr" <wineforum-user@winehq.org> writes:
In a private project of mine I currently follow this approach: Users
will have to specify the Wine version they are running, as a command
line parameter. If they don't, the app will either not work or crash
with current versions of Wine. There is no other way, otherwise I
cannot work around limitations that Wine has, but I believe will not
get fixed any time soon, given the fact that I submitted bug reports
almost a year ago. It would be a helluva lot easier if there were a
way to get the Wine version and let my app apply its compatibility
code paths with a priori knowledge it has about certain Wine
versions. Hey, I have to do the same thing for Windoze9x vs. NT
vs. Windows 2000 vs. XP vs. W2K3 server vs. ..... why does Wine make
it so hard for me to help my apps make the best use of it?
Check ntdll.get_wine_version(). It's not a good idea to add workarounds
based on the version, but if you really want to, it's there.

Just don't expect Wine to maintain any sort of backwards bug
compatibility; if a bug you worked around gets fixed and that breaks
your app it's your problem.

--
Alexandre Julliard
julliard@winehq.org

Stefan Kuhr
Newbie
Newbie
Posts: 4
Joined: Sun May 31, 2009 10:27 am

Re: How can I detect WINE from my program?

Post by Stefan Kuhr » Fri Jun 05, 2009 5:45 am

Hello Alexandre,
Alexandre Julliard wrote:"Stefan Kuhr" <wineforum-user@winehq.org> writes:

Check ntdll.get_wine_version(). It's not a good idea to add workarounds
based on the version, but if you really want to, it's there.
Please excuse my ignorance, but what is the exact prototype and calling convention for this function, so I can do a GetProcAddress on it and execute it? I have searched the Wine sources but could not find this function anywhere. I have Wine version 1.1.22.

Thanks,

--
Stefan Kuhr

David Gerard

How can I detect WINE from my program?

Post by David Gerard » Fri Jun 05, 2009 6:26 am

2009/6/4 oiaohm <wineforum-user@winehq.org>:
Bug numbers sound fine in theory.  Until you wake up Wine bugzilla has been compacted 6 times so far.   Closed bugs removed and new bugs give there bug numbers.    Yes wine recycles bug numbers.
WHAT?

What does Wine possibly gain from hiding old bugs in this way?


- d.

Alexandre Julliard

How can I detect WINE from my program?

Post by Alexandre Julliard » Fri Jun 05, 2009 7:09 am

"Stefan Kuhr" <wineforum-user@winehq.org> writes:
Please excuse my ignorance, but what is the exact prototype and
calling convention for this function, so I can do a GetProcAddress on
it and execute it? I have searched the Wine sources but could not find
this function anywhere. I have Wine version 1.1.22.
const char *wine_get_version(void);

It's in dlls/ntdll/misc.c.

--
Alexandre Julliard
julliard@winehq.org

Stefan Kuhr
Newbie
Newbie
Posts: 4
Joined: Sun May 31, 2009 10:27 am

Re: How can I detect WINE from my program?

Post by Stefan Kuhr » Fri Jun 05, 2009 8:08 am

Hi Alexandre,
Alexandre Julliard wrote:"Stefan Kuhr" <wineforum-user@winehq.org> writes:
Please excuse my ignorance, but what is the exact prototype and
calling convention for this function, so I can do a GetProcAddress on
it and execute it? I have searched the Wine sources but could not find
this function anywhere. I have Wine version 1.1.22.
const char *wine_get_version(void);

It's in dlls/ntdll/misc.c.

--
Alexandre Julliard
julliard@winehq.org

Ah I see, it is wine_get_version, not get_wine_version, that explains why I coudn't find it. Thanks, I will give that one a try. Can I expect that this function will remain an exported function of Wine's ntdll.dll in the future?

Again, thanks.

--
Stefan Kuhr

Alexandre Julliard

How can I detect WINE from my program?

Post by Alexandre Julliard » Fri Jun 05, 2009 8:23 am

"Stefan Kuhr" <wineforum-user@winehq.org> writes:
Ah I see, it is wine_get_version, not get_wine_version, that explains
why I coudn't find it. Thanks, I will give that one a try. Can I
expect that this function will remain an exported function of Wine's
ntdll.dll in the future?
It should remain available, unless we find an app that breaks because of
the extra export (but that seems unlikely).

--
Alexandre Julliard
julliard@winehq.org

austin987
Wine Developer
Wine Developer
Posts: 2383
Joined: Fri Feb 22, 2008 8:19 pm
Contact:

How can I detect WINE from my program?

Post by austin987 » Fri Jun 05, 2009 10:47 am

On Wed, Jun 3, 2009 at 9:49 PM, oiaohm<wineforum-user@winehq.org> wrote:
Bug numbers sound fine in theory.  Until you wake up Wine bugzilla has been compacted 6 times so far.   Closed bugs removed and new bugs give there bug numbers.    Yes wine recycles bug numbers.
No, it doesn't. Please make sure you know what you're saying before
spreading lies/misinformation.

--
-Austin

oiaohm
Level 8
Level 8
Posts: 1020
Joined: Fri Feb 29, 2008 2:54 am

Post by oiaohm » Fri Jun 05, 2009 10:33 pm

Vincent Povirk
If Wine is running on Linux, it can always be detected by making Linux syscalls. Wine cannot fix this.
Other than the fact the secuirty systems of Linux can watch syscalls. So calling 1 that wine don't use equal dead application. Yes it is even possible to block sys-calls from inside wine loaded exe's from the Linux system itself while allowing the dll.so files of wine perform syscalls. I do keep my eyes on what prototype secuirty systems exist.

Wine could make it simpler by the way. Method is what LUK has been doing. Add a set of syscalls to the OS kernel itself for wine. Using anything else could be disregard. Since the syscalls would be emulations of windows it would effectively render you blind. It is foolish to claim something cannot be fixed in software. Software everything basically can be fixed its a pure question of time and resources.

Wine does not need to fix this at this stage due to OS secuirty. I was not claiming wine contained a sandbox. Wine can be sandbox by the secuirty system in Linux. So leading to problems. Its so simple to think just because you detect wine that you can now do whatever you like. This is not windows. Doing whatever you like equals dead applications.

Problem with detecting wine without asking is if wine is sandboxed you end up doing things that get programs terminated. Most people planing work around most likely are planing to reach out to native code that can major upset the secuirty system of Linux.

If your work around sticks to wine and windows based code you are not going to get on the wrong side of the secuirty system.

Both wine and the secuirty system of linux are evolving. There is a correct path that will never harm. Ask.

You are looking at wine alone and forgetting the OS around it. Not a wise move.

David Gerard and austin987 the bug clean outs don't happen often. Its simple case of search ability of database bigger the database the slow it is to search. Result is always a risk of a number being recycled from it. You can depend that a open bug number will never move. You cannot depend that the bug number in like 8 years time will refer to the same bug. Bugs are designed to be temporary records not record for all time. Also recycling of the number does not happen straight a way. You are talking years at least from the time it was taken from closed and sent to void before its reused. Problem here we still have people wanting to run in wine programs from windows 3.11. So any application using wine could be still in use in a 100 years time at the rate things are going.

Since it been on codeweavers server have been taken care of the bugzilla its been the most stable in its history. Problem here you do have to think longer time scales than even the time codeweavers has assisted wine. Before locking yourself into something.

Wine version numbers are for all time. Those will never be deleted from record due to needing to search. So never risk being recycled by mistake.

One case of bug recycle was caused by server crash by the way was not noticed for a few months then it was corrected. That could be enough to really screw up an application. History tells us not to trust bug numbers absolutely. They are data and open to problems. Wine has a really long history and only 6 major upsets in that time is a really low number.

Its very much like earthquakes. If you are in a zone they can happen you build house earthquake resistant. Thinking longer than 5 years is something really different to what normal windows coders have to do.

This is where we are butting heads. I am thinking huge timescales and history.

oiaohm
Level 8
Level 8
Posts: 1020
Joined: Fri Feb 29, 2008 2:54 am

Post by oiaohm » Fri Jun 05, 2009 10:42 pm

PS Wine runs on FreeBSD as well as Linux. Freebsd Jails allow you to reorder the syscall table anyway you see fit. So syscalling out could be syscalling to kill application.

Basically syscalling without knowing the OS and Security under wine is a fast way to get application killed.

Vincent Povirk

How can I detect WINE from my program?

Post by Vincent Povirk » Sat Jun 06, 2009 12:14 am

On Fri, Jun 5, 2009 at 10:33 PM, oiaohm<wineforum-user@winehq.org> wrote:
If Wine is running on Linux, it can always be detected by making Linux syscalls. Wine cannot fix this.
Other than the fact the secuirty systems of Linux can watch syscalls.   So calling 1 that wine don't use equal dead application.  Yes it is even possible to block sys-calls from inside wine loaded exe's from the Linux system itself while allowing the dll.so files of wine perform syscalls.  I do keep my eyes on what prototype secuirty systems exist.
It's certainly possible for a kernel to do such things, but it's misguided.

The ability to use syscalls directly isn't the problem. It's just an
example. I'll try to explain better.

Wine must interface directly with the host OS. It might be running in
a virtual machine or unprivileged user or chroot jail, but the fact is
there is a Unix-like system that Wine interacts with.

Wine and the application share a process. There is no security layer
between them. The application can branch directly to anywhere in Wine
code, whether or not it was meant to be at an entry point or even the
address of an instruction. It can mess with internal Wine data
structures with impunity. The fact is, from a security standpoint,
Wine and the software it runs are the same. If the software cannot be
trusted, the Wine libraries cannot be trusted either. That is what I
mean by saying Wine cannot provide any security.

OK, great, you can reject syscalls that don't come from the .dll.so.
Maybe now I'll just branch directly to an interrupt instruction in a
.dll.so that makes the syscall. Or maybe I'll find the file API's in
the C library. Heck, I bet if I branched to the right point in
NtOpenFile, I could fool it into accepting a Unix path. Who knows?

What you're talking about is creating a minefield. If I'm just trying
to do generic evil Unix-specific things, there's a fairly good chance
I'll run into a mine. But if I know how your specific system works and
make a directed attack against it, I can get through the minefield and
get to whatever it is Wine sees.

It's possible (even likely, given the hooking and other crazy stuff
they often do) that a real application that someone wants to run trips
one of these mines, and if that happens the user loses.

Assuming that you do not trust my program, "whatever it is Wine sees"
should be not particularly useful. If that doesn't break your
security, why bother setting up the crazy minefield that probably only
causes headaches for users? If it does break your security, well, then
it's already broken.
Wine could make it simpler by the way.   Method is what LUK has been doing.   Add a set of syscalls to the OS kernel itself for wine.   Using anything else could be disregard.   Since the syscalls would be emulations of windows it would effectively render you blind.  It is foolish to claim something cannot be fixed in software.   Software everything basically can be fixed its a pure question of time and resources.
I don't claim it cannot be fixed in software. I do claim it cannot be
fixed by a userspace library that shares a process with untrusted
code.
Wine does not need to fix this at this stage due to OS secuirty.  I was not claiming wine contained a sandbox.   Wine can be sandbox by the secuirty system in Linux.  So leading to problems.  Its so simple to think just because you detect wine that you can now do whatever you like.   This is not windows.  Doing whatever you like equals dead applications.

Problem with detecting wine without asking is if wine is sandboxed you end up doing things that get programs terminated.   Most people planing work around most likely are planing to reach out to native code that can major upset the secuirty system of Linux.
When I say that Wine cannot provide security, I don't mean that
running a program in Wine is automatically at least as insecure as
running it on Windows. Unix systems can provide great security, and
Wine can run Windows programs in those systems. Wine automatically
benefits from any security provided by the host system.

It can be sandboxed by the OS, just like any other program.

However, you are talking about a sandbox surrounded by mines instead
of nice padded walls. That's a new concept to me. It seems very silly
and likely to cause more problems than it solves.

If a distro does this, we'll have to explain to some users that Wine
is broken on that distro because the security guys are nuts.

If someone sets this up on his own machines, we may have to explain to
him that Wine is broken on his machines because he is nuts.

I'd worry that I may one day have to explain to you that Wine hates
you because you are nuts, but it sounds like you'd just blame the
application developer instead of asking me.

Vincent Povirk

oiaohm
Level 8
Level 8
Posts: 1020
Joined: Fri Feb 29, 2008 2:54 am

Post by oiaohm » Sat Jun 06, 2009 1:13 am

Protected loads of dll.so files can also be limited. You are describing same kinds of exploitation faults these secuirty designers are working against.

System call protection prototypes also prevents from entering libs through non exposed calls. Ie if the dll.so does not export it there you cannot enter execution there. The branching attack is included. From a wine point of view a .dll.so rendered not patch-able would not be a issue. Wine would work normally. Only programs doing things they should not be doing would be effected. Then if program wants to patch dll solution would be to provide a normal dll without syscall usage.

It is secuirty evolution. Major reason for security personal going after protecting .so is to reduce down the area exploitable.

The alteration makes a major difference. If a executable gets flawed and a .so file is using a higher function in a restricted way attackers options are now limited. Compared to executable gets flawed since access to syscall was provided to the application attacker can use syscall any way they see fit.

People have already thought up attacks like yours Vincent Provirk and used them against native Linux systems. So secuirty is evolution happens over time to render it useless. This is how Linux and other OS's like it react to secuirty problems.

Any application running in wine could find themselves completely walled in. Not by wine but by the OS around it.

By the way Vincent Provirk lot of nocd hacks and game cheats trip straight up over Linux secuirty even when it set on low because they try to edit forbin memory sections.

You are making a very big presume you are allowed to alter .dll.so in the first place even in memory. You don't have to be granted that right. The complete thing can be marked no executable and read only in the executable sections until call to .dll is performed. This does reduce buffer overflow flaws getting into executable memory by the way. Yep entry points can be 100 percent restricted. Editing is out. .dll.so not on a approved list by system secuirty also would not run syscalls either.

This is why presuming you have a hole in Linux secuirty is bad. One day it will be taken away from you and your application will snap. It will produce a nice little secuirty report saying what you tried to do.

You are simply failing to understand you cannot design under Linux and expect to use any form of secuirty hole. Doing so is asking for your application to fail.

The point here is if user knows what you want todo. They can open up the security system so you can. It is the application developers fault for the failure because they are trying to treat Linux like windows. Ie can just hack around anything. Linux will not take that method all the time.

If your application need to reach outside wine you simply need to be truthful.

Vincent Povirk

How can I detect WINE from my program?

Post by Vincent Povirk » Sat Jun 06, 2009 2:28 am

On Sat, Jun 6, 2009 at 1:13 AM, oiaohm<wineforum-user@winehq.org> wrote:
Protected loads of dll.so files can also be limited.   You are describing same kinds of exploitation faults these secuirty designers are working against.

System call protection prototypes also prevents from entering libs through non exposed calls.  Ie if the dll.so does not export it there you cannot enter execution there.  The branching attack is included.   From a wine point of view a .dll.so rendered not patch-able would not be a issue.   Wine would work normally.  Only programs doing things they should not be doing would be effected.   Then if program wants to patch dll solution would be to provide a normal dll without syscall usage.
Absolutely. Any particular attack I propose can probably be addressed
by an update, and of course I'm picking the obvious ones. The problem
is that to secure a system in this way, you theoretically have to
think of all of them, and you have to make Wine perfect (in that it
cannot be fooled into doing something it wouldn't normally be able to
coaxed into doing, since it is apparently trusted more than the
program is). By limiting the entry points, you reduce the ways to
interact with system dll's, but the possible interactions are still
quite complicated and effectively impossible to turn into a real
security boundary. I still have the general ability to mess with the
internal data structures of the Wine libraries and to give the
functions unexpected input, potentially bending them to my evil will.

Limiting the entry points must be costly to performance. Each attempt
to execute code on the other side of the boundary must cause an
exception so that it can be validated by the OS (and presumably some
alteration of virtual memory).

Patching system dll's in memory is a perfectly normal thing to do on
Windows, and if Wine cannot allow this then Wine is broken. Yes, it's
bad practice. Yes, it's prone to breakage even under normal (Windows)
circumstances if there is an update. But it is not uncommon on Windows
and so it must work on Wine.

We have a perfectly good security boundary between the process and
everything else. Why try to create another one within the process?
By the way Vincent Provirk lot of nocd hacks and game cheats trip straight up over Linux secuirty even when it set on low because they try to edit forbin memory sections.
That still makes Wine broken, even if OS limitations make it
unfixable. There are many bugs like that.
This is why presuming you have a hole in Linux secuirty is bad.  One day it will be taken away from you and your application will snap.    It will produce a nice little secuirty report saying what you tried to do.

You are simply failing to understand you cannot design under Linux and expect to use any form of secuirty hole.   Doing so is asking for your application to fail.
What I'm failing to understand is why you think the ability to see the
host OS from a Windows program running in Wine is anything like a
security hole. If Wine itself can do something, there's no security
reason that a Windows program shouldn't be able to do it.

Yes, trying to use Linux syscalls in a Windows program (as well as
branching to non-entry-points, messing with internal structures,
giving unexpected input, etc.) is evil and prone to breaking. There's
simply no reason to do it when there are better ways. For example, I
can use native Wine API's to convert paths and start, say, /bin/sh.
But this isn't about security. It's about compatibility (these evil
methods make assumptions that may not always be true) and respecting
the user (if the user does choose to not map /, going around the drive
mappings is simply rude).

oiaohm
Level 8
Level 8
Posts: 1020
Joined: Fri Feb 29, 2008 2:54 am

Post by oiaohm » Sat Jun 06, 2009 9:27 am

Funny enough limiting entry points does not cost that much. Average .so calls on Linux are still less than the windows call to a dll when anti-virus is running. Pax did it on Linux for a long time.

Again presuming non exported memory zones have to be marked read write when in application context. So the internal memory structs of .so can be off limits. This is currently not done without real high need. There is no exploit there that the code for the complier and mandatory access control systems cannot activate. It is a simple case of ownership tracking.

Simple reason that you are not getting. Linux secuirty could be set like fort knox. Its designed to lock the system down to make any attack as hard as possible minor costs to performance are tolerated. The cost is way less than running an anti-virus on windows. Linux hidden heuristic anti-virus is the mandatory access control system. Yes there are two paths to do heuristics. One is have a stack of signatures and search every program you run against them that comes with about a 20 percent cpu overhead. Or the second remove means to tamper that comes with about a 2 percent cost. Linux has chosen the latter yes locking entry points and internal memory in selected .so files cost nothing compared to running signatures on everything.

Normal win32 applications running in wine will never need to reach out to the OS. So mandatory access control profile creators would be perfectly in there rights to forbid this. For the small numbers of applications that do it rules could be customized. So maintaining max strength against intrusion. Informing you uses that you require to do this is required so mandatory access controls can be opened up if required.

Large section of wine dlls can be built for windows by the way. So don't interact with Linux syscalls directly so would not need to be protected from tampering. For over 90 percent of all windows applications out there the mandatory access control policy could be set to max on all syscall locations with memory protection and rest of wine forbin from using syscalls. Because the dll you normally would tamper with under windows have no ability to do anything to breach the sandbox.

Even if there was a reason why you need to tamper with a protected dll this is still no reason why the syscall could not be moved into a internal and controlled .so that does not exist on windows. In that case application trying to directly access internal .so could be classed as an attack. One of the prototype mandatory access control systems does flow monitoring between .so files.

There is no way out. You have to accept this. If there is a way around the mandatory access control system you have found a flaw in the mandatory access control system that needs fixing.

If user does not want you going to / they can set it in the secuirty profile on wine. You go around the drive mappings could land in instant application termination even using the mappings you cannot presume you have been granted the rights to run /bin/sh if you have not asked for that right. Linux developers are use to these restrictions. This is why applications have list of parts they depend on under Linux so secuirty can be set right for them. Instant termination when a person is half way through working on something does not make them happy with you.

You have just become what you would call an anti-virus false positive that blocked your program from running and terminated it.

Basically you are talking about breaking a anti-virus. Should not a anti-virus kick you in the teeth for doing something strange. Linux mandatory access controls have not worries about doing it.

If Linux does come under major threat from viruses its mandatory access control systems will have to be turned up. Effectively closing the door on the viruses and any miss behaving applications.

Vincent Povirk

How can I detect WINE from my program?

Post by Vincent Povirk » Sat Jun 06, 2009 11:22 am

On Sat, Jun 6, 2009 at 9:27 AM, oiaohm<wineforum-user@winehq.org> wrote:
Again presuming non exported memory zones have to be marked read write when in application context.   So the internal memory structs of .so can be off limits.   This is currently not done without real high need.   There is no exploit there that the code for the complier and mandatory access control systems cannot activate.  It is a simple case of ownership tracking.
There will always be something else.

If you want real security, you need a GENERAL PRINCIPLE that can be
applied two all points of interaction between two things.
There is no way out.   You have to accept this.  If there is a way around the mandatory access control system you have found a flaw in the mandatory access control system that needs fixing.
Sure, the individual cases can be fixed, but this is an approach of
starting with an assumption that's fundamentally flawed (Wine
libraries and the running application can be treated differently) and
fixing individual cases. Things will always be missed. There is always
a way out. It's not a sound approach.

There is an opposite approach that you can take: Isolate each running
application (and, in cases where it makes sense, further divisions
within an application, enforced by actually having separate processes)
from each other and from data that belongs to the user. You can then
enumerate the points of interaction and secure them. Essentially, you
start with something secure (but also useless), and allow things as
needed, in a sound way, until it is useful. This approach can provide
real security. The other one can't.
If user does not want you going to / they can set it in the secuirty profile on wine.  You go around the drive mappings could land in instant application termination even using the mappings you cannot presume you have been granted the rights to run /bin/sh if you have not asked for that right.  Linux developers are use to these restrictions.   This is why applications have list of parts they depend on under Linux so secuirty can be set right for them.   Instant termination when a person is half way through working on something does not make them happy with you.
No, but on a normal system I can assume that if I don't have the
rights to /bin/sh, the attempt will just fail.

If a user CONFIGURES HIS SYSTEM to instantly terminate apps when they
do something he doesn't expect, I don't see how he could be unhappy
when it happens. Surely he should be happy that his security system
has protected him from the document he was working on.
You have just become what you would call an anti-virus false positive that blocked your program from running and terminated it.

Basically you are talking about breaking a anti-virus.    Should not a anti-virus kick you in the teeth for doing something strange.   Linux mandatory access controls have not worries about doing it.

If Linux does come under major threat from viruses its mandatory access control systems will have to be turned up.  Effectively closing the door on the viruses and any miss behaving applications.
If Linux does come under major threat from viruses, you'll also likely
see a corresponding change in Windows software. Developers will start
targeting Wine as an actual platform (in fact, a few do it already).
And they will take advantage of the fact that Wine runs on a Unix-like
system. Inevitably even apps that don't will trip mines. The end
result is that such a minefield security system will make Wine appear
broken to the user. People don't want to dig into software
configurations when things don't work. They want things to just work.
Users will only see that the system does not work and use something
else.

Tahtu
Newbie
Newbie
Posts: 1
Joined: Sat Jun 20, 2009 3:20 pm

Post by Tahtu » Sun Jun 21, 2009 1:46 am

vitamin wrote:However keep in mind that fixing Wine is always a most preferred solution.
8 month ago I reported a bug - together with a suggestion how to fix it inside the source code. I was just one line to change.

This week the fix has been overtaken.

I'm sorry, but I for myself really not motivated to assist a team who needs so much time, if I suggest a fix directly inside the related source code.


I'm thinking to allow the usage of my shareware application under Wine for free. So native Windows user should pay for it - but not Wine users. I'm thinking about this to support Linux and Wine in respect of all the work.

To do this I need a way to detect Wine as well.

So imho this is a good reason to allow Windows programs to detect Wine.


Since Wine is still very buggy and I'm not motivated to bother my users 8 month with a Wine bug - I would implement work a rounds into my application. For this I need to detect the Wine version as well.


PS
Please do not answer this posting. This is not a request about help - it's a note to think about it...

Locked