The next step is to isolate the Windows applications: you could use different WINEPREFIX, but I think the better way is to do it like android: one "user" per application.
It's not just to prevent applications to read other applications files, but also to firewall each application individually
For example, if you don't want the application you've mapped to user id 1001 to have any networking, use iptables with '-m owner --uid-owner 1001 -j DROP'
I moved from Windows to Linux a few years ago, I have a few Windows apps I still love a lot (mostly Word and Excel) and thanks to wine I will always be able to use them.
They are also extremely fast: cold starting Word (or Excel) on my laptop takes less than a second, and use far less RAM
Personally, I'd rather purchase a few shrink wrapped old versions of Office from ebay than bother with LibreOffice, Abiword or the online version of Office.
> but I think the better way is to do it like android: one "user" per application.
This would help somewhat, assuming you don't run them all in one user's X session. On Linux, some desktop environments have a "switch user" action to start a separate desktop session running as another user on another virtual console. You can switch between them with Control+Alt+F2, etc.
> In case you're not aware, wine prefixes each use their own settings, but are not isolated from one another.
That's a great point!
I'm aware, which is why recommend instead that wine apps should each be run under a different userid: I don't want any given app to have access to anything that it doesn't absolutely need
> This would help somewhat, assuming you don't run them all in one user's X session
When I start a given wine app, the script starting it allows this user id to render on my Xwayland
It is not as secure as running each on its own X session, but wayland compositors can offer more isolation as needed.
Lutris creates dedicated wine prefixes for the applications/games, so you can use it directly. A lot of apps are also installable with some patches provided by Lutris itself
> It's not just to prevent applications to read other applications files, but also to firewall each application individually
Why would one want to prevent applications from reading other applications' files?
We're talking about running desktop applications designed for an OS that isn't built around any concept of application isolation, and for which using a common filesystem is a primary mechanism of interoperability.
> Why would one want to prevent applications from reading other applications' files?
Because I can, and because I don't trust Windows application to be secure.
Thanks to that, I have no problem running 15 year old office software: even if I knew it was malicious, I also know there's nothing it can do without network access, without file access, and with resources constrains (so it can't even cause a denial of service, except to itself).
In the worst case, I guess it could try to erase its own files? (but it would then be restored from an image on the next run, and I would keep going)
> I have no problem running 15 year old office software: even if I knew it was malicious, I also know there's nothing it can do without network access, without file access
Great. Except... WTF can you do with an office application that can't read or write files?
I don't have the specific setup archived, but I believe my basis for it was a script included in winetricks at the time which installed Office 2013 professional based on offline 2013 proplus 32bit iso.
WineHQ reports that installer for 2013 64bit is "gold", but apps required few tweaks to be applied and Access sometimes failed.
Generally seems 2013-2016 era works on wine per few applications I checked
