wine users - Jan 2010 - what information can program get about underlying system

Hello,

I frequently run untrusted programs through wine and wonder, how much of
underlying linux system do I expose to those programs. I believe, that wine is
quite free of bugs, but I am not an expert of Windows API and the level wine
implements them.

I am particularly interested in these issues:

* If I do not connect my filesystem to wine in any way (through winecfg), is
there a possibility to untrusted program to read anything outside .wine/drive_c
directory?
* Is there any possibility for that program to access internals of my system
(like things in /proc, for example currently running processes).
* Is there any way to get information what exact graphics subsystem I am running
(e.g. version of X server etc.)?

Regards,
buratinas

2010/1/9 buratinas <wineforum-user at winehq.org>:
> I am particularly interested in these issues:
> * If I do not connect my filesystem to wine in any way (through winecfg),
is there a possibility to untrusted program to read anything outside
.wine/drive_c directory?
> * Is there any possibility for that program to access internals of my
system (like things in /proc, for example currently running processes).
> * Is there any way to get information what exact graphics subsystem I am
running (e.g. version of X server etc.)?

A program running in Wine has all the power of the user it runs as. If
you run it as you, it can do anything you can.

Wine slightly sandboxes Windows applications, but it *does not*
promise security - because it can't promise security. A "Windows"
binary running under Wine can still execute an INT 0x80 to run a Linux
system call, and break out of .wine and do anything on the system that
the user it's running as can do.

c.f. ZeroWine, a system for testing viruses and malware (known
malicious software) in Wine - it runs Wine in Debian in QEMU,
completely isolated from the host system, to avoid it doing anything
horrible.


- d.

> Wine slightly sandboxes Windows applications, but it *does not*
> promise security - because it can't promise security. A
"Windows"
> binary running under Wine can still execute an INT 0x80 to run a Linux
> system call, and break out of .wine and do anything on the system that
> the user it's running as can do. 

This is not exactly 100 percent correct.   Linux Secuirty Modules can restrict
on a application by application base.  Ie user by user base is the lazy our most
common users.  Application run as wine can do what ever the host OS is
configured to allow it to do.

selinux sandboxing does work around wine.  There are other containment options
as well.   Wine is not a secuirty system.   Wine does nothing to stop OS
provided secuirty systems from being used to contain it.

Thank you for answers. After some research I figured out that AppArmor fits my
needs quite well.

However, even if I disable access to the kernel internals and filesystem, one
problem is left unsolved: can untrusted program access any other X server
resource except its own window? Suppose I am running something infected in the
background and entering something confidential in a gnome application, can the
virus take a screenshot? For the sake of clarity, running the untrusted program
is more of necessity, not a mere convenience.