Using `--dotwine path:rw` with a non-exclusive wineprefix has issues

[cadrian]

Hi,

Unless I missed something obvious, --network does not work in combination with --dotwine.

sandwine --pass /opt/wine-stable:ro --network ipconfig /all

(sanitized output)

    Hostname. . . . . . . . . . . . . : 4c38939ba45a
    Primary DNS suffix. . . . . . . . :
    Node type . . . . . . . . . . . . : Hybrid
    IP routing enabled. . . . . . . . : No

Ethernet adapter lo

    Connection-specific DNS suffix. . : XXXX.com
    Description . . . . . . . . . . . : lo
    Physical address. . . . . . . . . :
    DHCP enabled. . . . . . . . . . . : No
    IPv6 address. . . . . . . . . . . : ::1
    IPv4 address. . . . . . . . . . . : 127.0.0.1
    Default gateway . . . . . . . . . :

Ethernet adapter enp3s0

    Connection-specific DNS suffix. . : XXXX.com
    Description . . . . . . . . . . . : enp3s0
    Physical address. . . . . . . . . : XXXX
    DHCP enabled. . . . . . . . . . . : No
    IPv6 address. . . . . . . . . . . : XXXX
    IPv6 address. . . . . . . . . . . : XXXX
    IPv6 address. . . . . . . . . . . : XXXX
    IPv4 address. . . . . . . . . . . : XXXX
    Default gateway . . . . . . . . . : XXXX

Unknown adapter wlp4s0

    Connection-specific DNS suffix. . : XXXX.com
    Description . . . . . . . . . . . : wlp4s0
    Physical address. . . . . . . . . : XXXX
    DHCP enabled. . . . . . . . . . . : No
    IPv6 address. . . . . . . . . . . : XXXX
    IPv4 address. . . . . . . . . . . : XXXX
    Default gateway . . . . . . . . . : XXXX

BUT

sandwine --pass /opt/wine-stable:ro --dotwine "$WINEPREFIX":rw --network ipconfig /all

    Hostname. . . . . . . . . . . . . : a6a662cdab8e
    Primary DNS suffix. . . . . . . . :
    Node type . . . . . . . . . . . . : Hybrid
    IP routing enabled. . . . . . . . : No

(yes, that's all)

By the way, is there a way to select which interface to allow and/or to randomize its physical address?

Thanks,

[hartwork]

@cadrian what's your value for ${WINESERVER} — that's an important detail! :smiley:

This works for me as expected:

sandwine --dotwine "$(mktemp -d | tee /dev/stderr)":rw --network ipconfig /all

I'll need more info to understand the issue.

[cadrian]

It is a simple $HOME/.wine_suffix

The reproduction is systematic. Here is a minimal script, without the extra stuff.

And with several tests, I found the problem. There is a strange interaction between direct calls to wine64 vs. calling sandwine on the same WINEPREFIX.

I added comments in the script, if that helps. Anyway, I have found a solution / workaround.

#!/usr/bin/env bash

export WINEPREFIX="$HOME/.wine_TEST"
export WINEARCH="win64"

wine() {
    sandwine --dotwine "$WINEPREFIX":rw --pass /opt/wine-stable:ro --network -- "$@"
}

rm -rf "$WINEPREFIX"

# Force Windows 11 ===>> NOTE!! calling the wine() wrapper instead of wine64 direct fixes the bug

#.. So, BUG:
wine64 winecfg /v win11
# .. NO BUG: (comment the line above and uncomment the line below)
#wine winecfg /v win11

# Remove managed and decorated as explained in the sandwine doc
wine reg add 'HKCU\Software\Wine\X11 Driver\' /v Managed /t REG_SZ /d N
wine reg add 'HKCU\Software\Wine\X11 Driver\' /v Decorated /t REG_SZ /d N

# Check network
wine ipconfig /all

[hartwork]

wine() {
    sandwine --dotwine "$WINEPREFIX":rw --pass /opt/wine-stable:ro --network -- "$@"
}

#.. So, BUG:
wine64 winecfg /v win11
# .. NO BUG: (comment the line above and uncomment the line below)
#wine winecfg /v win11

@cadrian I read these two combined as no bug with sandwine but bug without sandwine. Is this flipped around?

Note that sandwine does not use wine64 and not pass WINEARCH forward.

I'll need more help to understand the problem.

[cadrian]

@hartwork I don't know if it is a problem or only if there is something I don't understand.

In my script, when the .wine_TEST instance does not yet exist, it is created by the first winecfg invocation. And that behavior differs depending on whether I call wine64 or sandwine.

Your comment is correct: when I use only sandwine, there is no bug. :-)

So maybe I just wanted to point out that mixing native wine and sandwine on the same .wine instance does not work very well, if at all. My only question is: is it expected?

If yes, that's all right. Maybe just worth mentioning somewhere…

Also, I still have that question: is there a way to select which network interface to allow and/or to randomize its physical address?

Thank you

[hartwork]

So maybe I just wanted to point out that mixing native wine and sandwine on the same .wine instance does not work very well, if at all. My only question is: is it expected?

If yes, that's all right. Maybe just worth mentioning somewhere…

@cadrian that's an interesting question, because when the same wineprefix folder is used with and without the sandbox that means an attacker could delay an attack by putting things into the wineprefix from within inside the sandbox that no longer has limits applied once the folder is re-used outside the sandbox. It would even apply to say an image file with a zeroday that is picked up by a thumbnail pre-rendering daemon of the desktop environment. But those need to be turned off altogether anyway… Maybe it indeed needs an additional warning about re-using or sharing an existing folder.

I'll rename the ticket a bit to better show it's not specific to network but more broad or a problem.

Also, I still have that question: is there a way to select which network interface to allow and/or to randomize its physical address?

The short answer is no. The effect of --network can maybe best seen at…

https://github.com/hartwork/sandwine/blob/3f31b67dc8d7c2fa2376773a03a6d049ccba7591/sandwine/_main.py#L298-L304

…whereas --share-net is "Retain the network namespace" with regard to bubblewrap.