Confining wine

[curiosityseeker]

This project does not contain a profile for wine (but a wine abstraction). The (outdated) AppArmor wiki describes various methods how to confine wine applications.

I chose the first approach with profiles for wine-preloader and wineserver. It's working on my Arch (or, more specifically, CachyOS) system flawlessly in enforce mode. If it's not out of scope I could (after some more polishing) create a PR which should be regarded as a WIP. Since AppArmor 5.0 is not yet available, somebody else would have to add necessary dbus and unix rules.

What do you think?

[roddhjav]

Wine (and similar) can be used to run (almost) any windows software. Thus, directly confining wine, wine-preloader or wineserver would be like confining python. The resulting profile could do anything.

The solution targeted in this project it to confine the actual program / kind of program you have that, btw, will use wine. Hence the abstraction and no generic profile for wine. The result is that the wine abstraction is used in game (see umu-game or steam for instance).

To sum up profiles for windows based app are in scope, a profile for a generic wine is not.

[curiosityseeker]

Okay, this is fine for me. I can maintain those profiles for my own needs, no problem.

However:

Wine (and similar) can be used to run (almost) any windows software. Thus, directly confining wine, wine-preloader or wineserver would be like confining python. The resulting profile could do anything.

I don't really understand that. If wine, wine-preloader and wineserver are properly confined, followed by a rule like

owner @{HOME}/.wine/drive_c/** ix,

I don't get why you are saying that "The resulting profile could do anything". Yes, the wine applications are not isolated against each other, but they should not be able to cross the border of the wine world, IMO. What am I missing?

EDIT: Btw., I think the comparison to confining python is questionable. python apps need rw access to very different places, hence python itself cannot be confined. But wine apps need only w access to @{HOME}/.wine (with some clearly defined exceptions). That's why wine is much easier to confine.

[roddhjav]

1. @{HOME}/.wine/drive_c is the wine prefix and can be set dynamically and varies quite a lot depending on the runner.
2. The confined app itself, may need access to various user resources depending on the kind of the app (game, PDF reader, image processing, words, excel...)
3. Unless wine, wine-preloader and wineserver are really generic (ie: do not actually need access to the files mentioned in 2. they must be confined separatelly.
4. It would be however possible to have a app/windows abstraction that includes all shared resources required by a any app using wine/proton so that the final profiles would be minimal.