Hacker News new | ask | show | jobs
by jprjr_ 154 days ago
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
1 comments
avadodin 154 days ago
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.

link
ronsor 154 days ago
Users shouldn't be running random executables. Wine is not a sandbox!
link
avadodin 154 days ago
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.

link
ronsor 154 days 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.

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.

link
nice_byte 154 days ago
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.

link