sandwine 4.1.0

Description:

sandwine 4.1.0

What is sandwine?
sandwine is a command-line tool to run Windows applications on GNU/Linux
that offers more isolation than raw Wine
and more convenience than raw bubblewrap.
It uses Wine and bubblewrap (>=0.8.0), it does not replace them.
sandwine is Software Libre written in Python 3, and
is licensed under the "GPL v3 or later" license.
Installation
# pip3 install sandwine

Usage Examples
Install Winamp 5.66: no networking, no X11, no sound, no access to ~/* files
# cd ~/Downloads/
# sha256sum -c <(echo 'ac70a0c8a2928c91400b9ac3774b331f1d700f3486bab674dbd09da6b31fe130 winamp566_full_en-us.exe')
# WINEDEBUG=-all sandwine --dotwine winamp/:rw ./winamp566_full_en-us.exe /S /D='C:\Program' 'Files' '(x86)\Winamp' '5.66'

(The weird quoting in /D='C:\Program' 'Files' '(x86)\Winamp' '5.66'
is documented behavior
for NSIS.)
Run installed Winamp: with sound, with nested X11, no networking, no ~/* file access
# sandwine --pulseaudio --x11 --dotwine winamp/:rw --pass ~/Music/:ro --configure -- winamp

Argument --configure will bring up winecfg prior to Winamp so that you have a chance at
unchecking these two boxes:

Graphics:

Allow the window manage to *decorate* the windows
Allow the window manage to *control* the windows



If Winamp crashes right after showing the main window, run it once more,
there is some Wine bug at work here.
Run Geiss Screensaver: with sound, with host X11 (careful!), no networking, no ~/* file access
sandwine --host-x11-danger-danger --pulseaudio --retry -- ./geiss.scr /S

--host-x11-danger-danger make sandwine talk to the host X11 server, which would
expose you to keyloggers
so please re-visit your threat model before using --host-x11-danger-danger.
--retry is used to start programs a second time that consistently
crash from graphics issues in a fresh Wine environment
the first but not the second time.
Potentially a bug in Wine, needs more investigation.
PS: The Geiss Screensaver has its GitHub home at https://github.com/geissomatik/geiss .
Run wget: with networking, no X11, no sound, no access to ~/* files
# sandwine --network --no-wine -- wget -S -O/dev/null https://blog.hartwork.org/

Argument --no-wine is mostly intended for debugging,
but is needed here to invoke non-Wine wget.
Under the Hood
sandwine aims to protect against Windows applications that:

read and leak personal files through/to the Internet
read and leak keystrokes from other running applications
(related post)
modify/destroy personal files
modify/destroy system files

To achieve that, by default the launched application:

Sees no files in ${HOME} and/or /home/ (unless you pass --pass PATH:{ro,rw} for a related directory).
Does not have access to the internet (unless you pass --network).
Does not have access to your local X11 server
(unless you enable some form of X11 integration, ideally nested X11).
Does not have access to your sound card.

So what is shared with the application by default then?
What is Exposed by Default?
Files



Path
Content




/
new tmpfs


/bin
read-only bind mount


/dev
new devtmpfs


/dev/dri
read-write bind mount with device access


/etc
read-only bind mount


${HOME}
new tmpfs


${HOME}/.wine
new tmpfs


/lib
read-only bind mount


/lib32
read-only bind mount


/lib64
read-only bind mount


/proc
new procfs


/sys
read-only bind mount


/tmp
new tmpfs


/usr
read-only bind mount



Environment Variables

${DISPLAY}
${HOME}
${HOSTNAME} (with random 12-hex-digits value)
${PATH} (with known-unavailable entries removed)
${TERM}
${USER}

sandwine features include:

A focus on security, usability, transparency
Support for nested X11 provided by:

X2Go nxagent (seamless)
Xephyr
Xnest
Xpra (experimental, careful!)
Xvfb (invisible)


Support for PulseAudio
Support for /etc/resolv.conf provided by:

NetworkManager
systemd-resolved



Threat Model and Known Limitations

If your life depends on the sandbox, please consider using
a virtual machine rather than sandwine, e.g. because your username
is exposed to the running application and depending on your threat model,
that may be too much already.
sandwine is not intended for use with known-malicious software, viruses, malware.
sandwine has not seen any known external security audits, yet.
sandwine relies on bubblewrap
for its security, so it can only be as secure as bubblewrap.
sandwine does not limit the set of syscalls that the application can do.
bubblewrap supports arguments --seccomp and --add-seccomp-fd to go further
on that end, but sandwine does not use them so far.
sandwine does not keep the application from using loads of RAM, CPU time and/or disk space.
If your concerns include denial of service, you need protection beyond sandwine.
sandwine relies on sane file permissions in the places that are shared read-only.
If you have files in e.g. /etc that contain credentials but are readable by
unprivileged users, sandwine will do nothing to block that read access.
If the Windows application to be run expects a GNU/Linux environment and includes
Linux Kernel exploit code, then that exploit is not likely to be stopped by sandwine.
If you manually allow the sandboxed application to communicate with an unsandboxed application
and the latter executes commands for the former, then the sandbox cannot prevent privilege
escalation. Think of a model like the Docker daemon where whoever can talk to the Docker
daemon can become root. If you use sandwine with something like that, sandwine will have a problem.
Start-up time below 200ms is not a goal.

Reporting Vulnerabilities
If you think you found a vulnerability in sandwine,
please reach out via e-mail
so we can have a closer look
and coordinate disclosure.

Sebastian Pipping, Berlin, 2023