Dan Kegel wrote:
On Sat, Oct 24, 2009 at 10:47 PM, Nicholas LaRoche nlaroche@vt.edu wrote:
A few months ago there was a topic in wine-devel on the same subject. A toggle switch for portions of the wine API (i.e. networking), WINEPREFIX, and SELinux seems to make this a non-issue.
The default wine SELinux configuration for Fedora 11 denies quite a bit of behavior. (Try compiling and using HEAD without setting the security context or entering permissive mode and you'll see what I mean).
Does this even need to be handled at the wine level to prevent system-wide corruption? It seems like other security technologies already provide this protection.
We may want to lend a hand. For instance, I could imagine the system needing some help to figure out how to allow certain windows apps access to the network, and deny it to others. And I think sandboxing a la chromium might end up being a useful technique that would require some work on wine's part to work well.
- Dan
Sandboxing is certainly an interesting idea if we want to expand the role of Wine-specific packages (a la Picassa). I've been experimenting with shipping a Windows (or winelib) app via a distro package configured to run in its own prefix. This in particular could benefit from sandboxing, as then security holes in that application wouldn't take down the rest of the user folder.
Many apps don't need to view the user folder for documents but also employ programmable scripting engines - a good example are games. It would be much more convenient to pass some sort of "sandbox me, allow network, deny home folder access" switch to Wine than to muck about with stuff like AppArmor profiles.
Thanks, Scott Ritchie