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
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
-
Michael Stefaniuc -
Steven Stewart-Gallus