Protecting the OS with WINE?

Discussion in 'all things UNIX' started by amarildojr, Sep 11, 2017.

  1. amarildojr

    amarildojr Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    2,062
    Location:
    Brasil
    I've never been an avid WINE user. I think I only installed it briefly 3 times in the +12 years I've been using Linux.

    I'm also very paranoid these days, and considering cryptolockers can lock the files in my /home folder if I'm using WINE, and I now need WINE installed, I need to know how to completely prevent WINE from reading anything in my /home or / folder.

    Any ideas?
     
  2. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    1,064
    Well, there is a Firejail profile for wine (but I haven't tried it as I don't use wine - I only drink it). You might want to add some own blacklist rules. If you're using a distro which supports AppArmor that's another possibility. Furthermore, removing the z: drive is still a good trick.
     
  3. amarildojr

    amarildojr Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    2,062
    Location:
    Brasil
    Hah :argh:

    I don't use WINE too, and I've looked at the profile a few times and it always seems a bit relaxed, I don't know if this is because it's necessary or not.

    Like "blacklist /home/amarildo*" and then "noblacklist /home/amarildo/.wine"?

    Thanks.

    I'll be using Debian 9. I'm 99% sure it supports AppArmor. I just hope I don't have to re-compile the Kernel every time there's an update.

    Already had that in mind :thumb:
     
  4. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    1,064
    Well, the 3 *.inc files in that profile already block a lot but it is surely possible to tighten it.

    I'm not quite sure if that would would work. Besides, I remember that wine needs access to, e.g., ~/.local/share/applications. I would suggest that you try to create your own whitelisted profile as explained here. This makes sure that only those folders are whitelisted which are really needed. Create wine.profile in ~/.config/firejail, add your whitelist rules to that file and include the profile that comes with Firejail. Example:
    Code:
    whitelist ....
    whitelist ...
    
    include /etc/firejail/wine.profile
    You can also try to add
    Code:
    private-dev
    private-bin wine,wine-preloader,wine64,wine64-preloader,wineboot,winebuild,winecfg,wineconsole,winecpp,winedbg,winedump,winefile ... whatever
    in order to harden the profile even more. The latter needs probably some trial and error until all necessary binaries are added.

    No, Debian definitely supports AppArmor. You don't need to re-compile the kernel.
     
  5. SirDrexl

    SirDrexl Registered Member

    Joined:
    Apr 14, 2012
    Posts:
    554
    Location:
    USA
    You could run it as a different user.
     
  6. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    1,064
    I think that's inconvenient. By applying above measures you can get a very high security level, IMHO.
     
  7. amarildojr

    amarildojr Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    2,062
    Location:
    Brasil
    Thanks, summer! I will try that as soon as I can.

    Yes, logging with a dif user is very inconvenient, specially to someone like me who uses very long and complicated passwords :p
     
  8. Anonfame1

    Anonfame1 Registered Member

    Joined:
    May 25, 2016
    Posts:
    222
    Interesting... you switching to Debian amarildojr? Out of curiousity, are you worried about the application you use on Wine becoming compromised and moving into your /home, or an application on Debian infecting a wine application after being compromised?

    As summerheat mentioned, Debian has apparmor support straight away and it also has quite a few profiles. I would run firejail and apparmor personally- use firejail to reduce kernel exposure and apparmor for mandatory access control.

    Also, do you know if any Debian kernel uses the "linux-hardened" patchset used for Arch's linux-hardened kernel? That patchset is not what grsecurity was, but its coming along and adding quite a few protections. At this point its the best available kernel protection aside from grsecurity. I'll admit that I'm getting a little tired of compiling for apparmor support everytime linux-hardened gets a new kernel. Still, its what I know best (arch) and I dont know of any other distro packaging a kernel using that patchset.
     
  9. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    1,064
    I think the view that Firejail is only used to reduce kernel exposure (via seccomp-bpf and dropping capabilities) is a misconception. As Firejail uses SUID / namespaces / file system containers with blacklist, whitelist, read-only and noexec rules, a very granular control is possible of what an application is allowed to do. And with private-bin (for /sbin, /usr/bin, /usr/sbin, /usr/local/bin), private-etc, private-lib, private-opt and private-srv it's possible to restrict access to only specific files in those folders. I would say, that altogether this comes rather close to what AppArmor offers - while it's much easier to configure than the latter.
     
Loading...