What would the best approach for adding securing Wine and is it a reasonable goal?

[Michael Stefaniuc]

Hello Steven,

On 08/28/2015 02:44 AM, Steven Stewart-Gallus wrote:
> I noticed that CreateRestrictedToken basically just duplicates the token and
> doesn't do anything. This makes sense as Wine is implemented as a compatibility
> library and program loader and not as a virtual machine and Windows programs
> running on Wine can break out and access Linux system calls so making
> CreateRestrictedToken do anything more wouldn't accomplish anything. I think it
> would be really cool though if CreateRestrictedToken and similar sandboxing APIs
> actually accomplished something in Wine though.
> 
> What would the best approach for securing Wine be and is it a reasonable goal?
the easy point that people miss:
In this context Wine is an OS and what the people want is to secure
their application. Most attacks are targeting applications and not the
OS. So like on Linux it depends on the application on how to secure it.
So what helps to secure an app will break an other.

Is it a reasonable goal? Sure, if it scratches your itch and you want to
work on it then go ahead, nobody will stop you. A big part of this can
be developed outside of upstream Wine. You may want to check out
ZeroWine as that is a specialized project to analyze Windows malware in
a Wine sandbox.

But for the Wine project in general focusing on securing Wine has a huge
opportunity cost. Most of the Wine project members are working on
getting applications to run and run well under Wine. There is more than
enough work left there.

bye
	michael

> First, see http://wiki.winehq.org/SecuringWine. So far, I can think of a few
> approaches. The first approach is to make a whole operating system such as
> ReactOS. The second approach is making a whole operating system that only has
> device drivers for working on top of virtual machines or hypervisors. The third
> approach is making a kernel that runs as a normal user process on top of a full
> OS (similar to User-Mode Linux or a weekend project I am working on at
> https://gitlab.com/sstewartgallus/wum, also see the Chrome sandbox at
> https://www.chromium.org/developers/design-documents/sandbox,
> https://code.google.com/p/chromium/wiki/LinuxSandboxing and
> https://dev.chromium.org/developers/design-documents/sandbox/osx-sandboxing-design).
> The fourth approach is to abandon securing Wine itself and simply run Wine
> programs inside separate sandboxes.
> 
> ReactOS already serves as an example of the first approach.
> 
> The second approach is basically similar to ReactOS.
> 
> My project at https://gitlab.com/sstewartgallus/wum serves as a tiny example of
> of the third approach might work.
> 
> The fourth approach of separate sandboxes is actually very simple. One possible
> implementation of this fourth approach on Linux might be to use a script like
> the sandbox-X.sh script shown below and remove the Z: symlink in dosdevices
> (this isn't actually needed or improves security but just looks nice.) Note that
> to make this script work I had to do some configuration to let my automatically
> su into the sandbox account. As well, I also had to download a dummy Xorg
> configuration to the home directory of the sandbox account.
> 
> Thank you,
> Steven Stewart-Gallus
> 
> sandbox-X.sh:
> #! /bin/sh
> 
> set -e
> set -C
> set -u
> 
> exec su -l -c 'exec sh <&3' sstewartgallus-sandbox 3<<'EOF'
> set -e
> set -C
> set -u
> 
> exec 3<&-
> 
> export DISPLAY=':76'
> export XPRA_SOCKET_DIR='/tmp'
> exec xpra\
>     start\
>     ${DISPLAY}\
>     --xvfb="Xorg -noreset +extension GLX +extension RANDR +extension RENDER
> -logfile ./${DISPLAY}.log -config ./xorg.conf"\
>     "--no-daemon"\
>     "--mmap-group"\
>     "--no-sharing"\
>     "--bell"\
>     "--system-tray"\
>     "--xsettings"\
>     "--cursors"\
>     "--encoding=rgb"\
>     "--clipboard"\
>     --start-child=xterm
> 
> 
>