[Wine] How can I detect WINE from my program?

[Vincent Povirk]

On Fri, Jun 5, 2009 at 10:33 PM, oiaohm<wineforum-user at 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