[avadodin]

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.

[ronsor]

Users shouldn't be running random executables. Wine is not a sandbox!

[avadodin]

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.

[ronsor]

> 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.

[nice_byte]

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.