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

[Steven Stewart-Gallus]

Hello,

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?
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-...).
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

[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-...).
> 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