Various anticheat/DRM schemes actually do direct syscalls on Windows, so Proton has patches that use seccomp to trap them and jump to the intended Nt* syscall. There was actually a feature added to the Linux kernel a few years ago (syscall user dispatch) so that Wine could stop using seccomp for this, but Wine is still not using it.
Upstream Wine also supports direct syscalls on x86_64 macOS. macOS syscall numbers have a high bit set, so Windows syscall numbers (0 to ~300) are invalid macOS syscalls, that triggers SIGSYS, and then Wine jumps to the Nt* syscall.
There's actually a couple of reasons for Windows apps to make Linux syscalls. I'm pretty certain this is how VST bridging software works so you can use Windows VSTs in Linux DAWs.
The average user expectation is probably not that any random exe they download from the piratehub or whatever can actually run Linux shellcode on their system.
I think all syscalls should be landlocked by default(It might require a novel kernel-assisted mechanism to keep existing official Wine libraries working, not sure).
Some of these programs with Wine support will have to get grandfathered in, of course, but at least let the user add them to a white list with a confirmation popup.
"This program wants to run Linux h4x0r shellcode. Allow?"
And then of course provide a mechanism so that new Wine-aware applications can interact with Linux features in a safer way.
Wine is not a Sandbox but come on. Everyone has been using it as if it was.
Even Bottles was only a prefix-manager until a couple months ago.
I think it should be and also disallow Linux syscalls and Z: drive accesses by default from within the "sandbox" on top of that in order to reduce the attack surface.
> I think it should be and also disallow Linux syscalls and Z: drive accesses by default from within the "sandbox" on top of that in order to reduce the attack surface.
This is not even remotely sufficient. A malicious application could modify the memory pages of WINE code and execute direct syscalls anyway.
If you want sandboxing, use a Linux sandboxing solution on WINE. It's far too late to try to bolt on sandboxing now.
it would be hard to say whether a given program making a syscall is trying to do a native linux sys call or a "naked" windows syscall (something that some windows programs actually do).
but yeah, somehow intercepting syscalls is a prerequisite for either emulating these naked windows syscalls or notifying the user about the native linux ones.
I've done this before. There are valid reasons to do this, especially if you're too lazy to do a full Linux port of an application but are still willing to implement some workarounds.
Related, there is a stable way to detect whether your .exe is running under Wine and even which version by looking up the address of the export wine_get_version in ntdll [1]. Years ago I actually had to do this to work around some weird path bug when we were testing our Windows build under Wine (easier to setup Wine than a full Windows CI).
Various anticheat/DRM schemes actually do direct syscalls on Windows, so Proton has patches that use seccomp to trap them and jump to the intended Nt* syscall. There was actually a feature added to the Linux kernel a few years ago (syscall user dispatch) so that Wine could stop using seccomp for this, but Wine is still not using it.
Upstream Wine also supports direct syscalls on x86_64 macOS. macOS syscall numbers have a high bit set, so Windows syscall numbers (0 to ~300) are invalid macOS syscalls, that triggers SIGSYS, and then Wine jumps to the Nt* syscall.
There's actually a couple of reasons for Windows apps to make Linux syscalls. I'm pretty certain this is how VST bridging software works so you can use Windows VSTs in Linux DAWs.
The technique is also used in Discord RPC Bridge for Wine - allows Wine apps to communicate with Linux Discord - https://github.com/EnderIce2/rpc-bridge
The average user expectation is probably not that any random exe they download from the piratehub or whatever can actually run Linux shellcode on their system.
I think all syscalls should be landlocked by default(It might require a novel kernel-assisted mechanism to keep existing official Wine libraries working, not sure).
Some of these programs with Wine support will have to get grandfathered in, of course, but at least let the user add them to a white list with a confirmation popup.
"This program wants to run Linux h4x0r shellcode. Allow?"
And then of course provide a mechanism so that new Wine-aware applications can interact with Linux features in a safer way.
Users shouldn't be running random executables. Wine is not a sandbox!
Maybe change the name to Wins?
Wine is not a Sandbox but come on. Everyone has been using it as if it was.
Even Bottles was only a prefix-manager until a couple months ago.
I think it should be and also disallow Linux syscalls and Z: drive accesses by default from within the "sandbox" on top of that in order to reduce the attack surface.
> I think it should be and also disallow Linux syscalls and Z: drive accesses by default from within the "sandbox" on top of that in order to reduce the attack surface.
This is not even remotely sufficient. A malicious application could modify the memory pages of WINE code and execute direct syscalls anyway.
If you want sandboxing, use a Linux sandboxing solution on WINE. It's far too late to try to bolt on sandboxing now.
it would be hard to say whether a given program making a syscall is trying to do a native linux sys call or a "naked" windows syscall (something that some windows programs actually do).
but yeah, somehow intercepting syscalls is a prerequisite for either emulating these naked windows syscalls or notifying the user about the native linux ones.
I've done this before. There are valid reasons to do this, especially if you're too lazy to do a full Linux port of an application but are still willing to implement some workarounds.
Related, there is a stable way to detect whether your .exe is running under Wine and even which version by looking up the address of the export wine_get_version in ntdll [1]. Years ago I actually had to do this to work around some weird path bug when we were testing our Windows build under Wine (easier to setup Wine than a full Windows CI).
[1] https://www.winehq.org/pipermail/wine-devel/2008-September/0...