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.
[1] https://www.winehq.org/pipermail/wine-devel/2008-September/0...
jprjr_•3w ago
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
avadodin•3w ago
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.
nice_byte•3w ago
but yeah, somehow intercepting syscalls is a prerequisite for either emulating these naked windows syscalls or notifying the user about the native linux ones.
ronsor•3w ago
avadodin•3w ago
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.
ronsor•3w ago
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.