This post documents my experiment on using wine to prevent windows applications from using linux syscalls to access the filesystem, while still allowing the wine-provided Windows API to function normally.
Introduction: A lot of people want to use wine for sandboxing Windows programs, but there are so many ways to break out of it and call linux API directly: Z:, \\?\unix\, .exe.so, wine private functions, syscall, ...
What people overlook is that breaking out of wine doesn't necessarily compromise a sandbox. Note that wine, for the sake of compatibility, already has to shove most filesystem API calls to wineserver over a socket. This is pretty like the Xorg situation, where a high privilege server does stuff on behalf of a low privilege client. That leads to a natural question: what happens if we run wineserver under a non-root-but-has-something user and run wine under a sandboxed minimal-privilege user?
It turns out wine has taken lengthy measures to make sure all the wine stuff are run under the same user, presumably to prevent registry corruption. The protection measures aren't absolute, though, and we can still do a proof-of-concept experiment around it. Here is my experiment setup:
1. Create two linux users MAIN and SANDBOX. Supposedly, the user MAIN doesn't want Windows applications to access her files using Linux syscalls. Don't use your real users for this, as any mistake would corrupt their wineprefixes.
Note: Neither user has to be a sudoer.
2. MAIN creates a normal wine prefix in some world readable place: /xxx/.wine
SANDBOX needs to have +x permission to be able to chdir within this wine prefix, but doesn't need +r beyond /xxx/.wine/drive_c, and doesn't need +w at all.
3. As MAIN, run WINEPREFIX=/xxx/.wine wineserver -p
4. As root, do a bunch of hacks to get around wine checks:
chown SANDBOX /xxx/.wine
ls /tmp/.wine-`id -u MAIN`/
You should see a server-...-..... directory here, which holds MAIN's wineserver socket. We now fake a similar directory for SANDBOX and hardlink the sockets in.
mkdir /tmp/.wine-`id -u SANDBOX`
mkdir /tmp/.wine-`id -u SANDBOX`/server-...-...../
ln /tmp/.wine-`id -u MAIN`/server-.../lock /tmp/.wine-`id -u SANDBOX`/server-...-...../lock
ln /tmp/.wine-`id -u MAIN`/server-.../socket /tmp/.wine-`id -u SANDBOX`/server-...-...../socket
chown -R SANDBOX /tmp/.wine-`id -u SANDBOX`
chmod -R a-rwx /tmp/.wine-`id -u SANDBOX`
chmod -R u+rwx /tmp/.wine-`id -u SANDBOX`
Note that these root hacks won't be required if one removes the safety checks from wine code and removes the uid component from the socket path.
5. Run windows application under that wineprefix as user SANDBOX, e.g.:
su SANDBOX
WINEPREFIX=/xxx/.wine wine cmd
6. The wine cmd is able to read/write files normally in that wineprefix, but if you enable Z: (as root) and call things like /bin/ls or /bin/sh, you actually LOSE that access, since the linux user SANDBOX, who runs the wine loader, doesn't have the necessary privileges.
Now this creates an interesting situation: the Windows program can easily break out of the wine emulation, but can't gain anything by doing that. In fact, it couldn't even read/write its own C: by calling linux functions directly. I believe this may actually make wine a viable sandbox for running (potentially) malicious Windows programs, if only wineserver could be hardened a bit.
Note: Currently, the Windows program should still be able to access the entire filesystem from this sandbox with MAIN's privilege by calling CreateFile with a \\?\unix\ path. Also, the Windows program would still encounter a few rough edges, e.g. it can't rename files or kill processes (even those spawned by itself). These issues could be easily fixable by patching wine, though.
